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FOREWORD 


To  ensure  that  the  U.S.  Army's  future  weapon  systems  are  usable  by 
soldiers,  the  U.S.  Army  Research  Institute  for  the  Behavioral  and  Social 
Sciences  (ARI)  investigates  human  performance  issues  related  to  prototype 
weapon  systems.  Simulation  of  weapon  systems  and  particularly  user  interfaces 
to  these  systems  provides  ARI  researchers  with  a  medium  for  addressing  human 
performance  issues  such  as  usability,  training,  and  personnel  requirements 
during  the  earliest  stages  of  weapon  system  development.  This  report  presents 
a  set  of  design  guidelines  and  specifications  for  developing  a  simulation- 
based  prototype  user  interface  to  automated  command,  control,  and  communica¬ 
tion  (C^)  systems  for  lower  echelon  forces. 

This  report  by  the  ARI  Field  Unit  at  Fort  Knox  was  prepared  under  Science 
and  Technology  Task  3.5.1,  "Training  Requirements  for  NBC  and  the  Future  Inte¬ 
grated  Battlefield."  ARl's  involvement  in  research  011  future  battlefield 
conditions  supports  the  Memorandum  of  Understanding  between  ARI  and  the  U.S. 
Army  Armor  Center  and  School  (USAARMC&S)  on  Land  Battle  Test  Bed  Research 
signed  9  January  1986.  The  Directorate  of  Combat  Developments  at  Fort  Knox 
has  reviewed  and  approved  these  guidelines  and  specifications.  The  report  has 
been  provided  to  design  engineers  contracted  by  the  Defense  Advanced  Research 
Projects  Agency  (DARPA)  to  initiate  the  development  of  a  simulated  Battlefield 
Management  System  (BMS)  interface  that  can  be  rigorously  evaluated  and  modi¬ 
fied  with  respect  to  soldier  performance  and  training  issues  in  the  task- 
loaded  environment  provided  by  a  simulation  network  (SIMNET) .  In  addition, 
this  product  was  provided  to  representatives  of  the  Tank  Automotive  Command 
(TACOM)  and  the  Communications  Electronics  Command  (CECOM)  for  review  by 
system  hardware  engineers. 


Acoession  For 

NT  IS  GRAAT. 

DTIC  TAB 

□ 

Unannounced 

□ 

Justification — 

By - - — 

Distribution/ 


Availability  Codes 

Dist 

rv 

Avail 

Spec 

and/or 

lal 

Preceding  Page  Blank 


DESIGN  GUIDELINES  AND  FUNCTIONAL  SPECIFICATIONS  FOR  SIMULATION  OF  THE 
BATTLEFIELD  MANAGEMENT  SYSTEM'S  (BMS)  USER  INTERFACE 


CONTENTS _ 

Page 

INTRODUCTION  .  1 

DISPLAY  CONFIGURATION  .  2 

DISPLAY  GUIDELINES  .  7 

Design  Guidelines  .  7 

User-Based  Guidelines  .  7 

Simulation  Guidelines  .  8 

Display  Functions  .  15 

COMMUNICATION  GUIDELINES  .  32 

Simulation  Guidelines  .  32 

C^  Documentation .  38 

Guideline  Applications  .  39 

POSNAV  GUIDELINES  .  48 

S*>SNAV  Specifications .  51 

Cpaatii  tuned  on  .  51 

Route  Designation  Function . 54 

Driver's  Display .  .  S? 

BMS  ENHANCEMENTS .  57 

REFERENCES . 60 

LIST  OF  TABLES 

Table  1.  Screen  layout  guidelines  .  10 

2.  Color  coding  guidelines  .  10 

3.  Blinking  code  guidelines .  11 

4.  Highlighting  code  guidelines  .  12 

vii 


Preceding  Page  Blank 


CONTENTS  (Continued') 


Page 

LIST  OF  TABLES  (Continued) 

Table  5.  Rationale  for  menu  dialogue  mode .  12 

6.  Menu  layout  guidelines .  13 

7.  Data  format  guidelines .  14 

8.  Touch  input  guidelines  .  14 

LIST  OF  FIGURES 

Figure  1.  BMS  user  interface .  3 

2.  IVIS  user  interface .  3 

3.  BMS  interface  at  approximate  9 -inch 

diagonal  size .  6 

4.  Map  functions .  17 

5.  Distance .  17 

6.  Free  draw .  19 

7.  Terrain  features .  19 

8.  Line  of  sight .  21 

9.  Measures .  21 

10.  Lines,  points .  24 

11.  Objectives,  areas,  positions  .  24 

12.  Overlays . 26 

13.  Review/update . 26 

14.  Terrain  relief .  28 

15.  Scroll .  28 

16.  Units .  30 


viii 


CONTENTS  (Continued') _ _ 

Page 

LIST  OF  FIGURES  (Continued) 

Figure  17.  Zoom .  30 

18.  Contact  report .  41 

19.  Call  for  fire  report .  41 

20.  NBC  report .  43 

21.  Status  menu .  43 

22.  Vehicle  status .  44 

23.  Engine  components  .  44 

24.  Drivetrain  status .  45 

25.  Gunnery  components  .  45 

26.  Personnel  status  .  46 

27.  Communication  types .  46 

28.  Report  types .  47 

29.  Spot:  Type,  strength  .  47 

30.  Spot:  Activity,  location  .  49 

31.  Spot:  Speed,  direction . 49 

32.  Spot  report  summary .  50 

33.  POSNAV  functions  .  52 

34.  Digital  update .  52 

35.  Map  update .  55 

36.  Designate  route .  55 

37.  Label  routes  and  waypoints  .  58 

38.  Driver's  display  .  58 

ix 


DESIGN  GUIDELINES  AND  FUNCTIONAL  SPECIFICATIONS  FOR 
SIMULATION  OF  THE  BATTLEFIELD  MANAGEMENT  SYSTEM'S  (BMS)  USER  INTERFACE 


INTRODUCTION 

The  Army  Research  Institute  (ARI)  conducts  applied  research  that  focuses 
ou  meeting  the  people-related  challenges  facing  the  Army  of  today  and  tomor¬ 
row.  As  part  of  ARI's  program  to  train  che  force,  the  objective  of  the  Fu¬ 
ture  Battlefield  Conditions  Team  is  to  enhance  soldier  preparedness  through 
Identification  of  future  battlefield  conditions  and  the  methods  for  training 
to  meet  those  conditions  (Science  and  Technology  Task  3.5.1).  Future  ad¬ 
vances  in  weapons  and  equipment  of  the  U.S.  Army,  however,  can  increase  our 
combat  effectiveness  only  if  those  systems  are  usable  by  our  soldiers.  To 
ensure  that  future  weapon  systems  are  useable,  ARI  investigates  human  per¬ 
formance  issues  related  to  prototype  weapon  systems.  In  addition,  ARI  pro¬ 
vides  guidelines  and  specifications  to  initiate  the  development  of 
soldier-machine  interfaces  that  will  support  the  empirical  resolution  of 
anticipated  human  performance  issues.  This  ARI  research  product  provides 
system  designers  with  a  set  of  design  guidelines  and  specifications  for  de¬ 
veloping  a  simulated  user  Interface  to  the  new  main  battle  tank's  battlefield 
management  system  (BMS).  BMS  is  an  integrated  complex  of  battlefield  infor¬ 
mation  acquisition  and  processing  technologies  intended  to  significantly 
enhance  lower  echelon  command  and  control  (C^). 

ARI's  primary  goal  in  this  effort  is  to  address  the  human  performance 
issues — usability,  training  and  personnel  requirements — associated  with  the 
anticipated  development  of  automated  command,  control  and  communication  (C3) 
systems  for  lower  echelon  Armor  units.  The  guidelines  and  specifications 
provided,  therefore,  focus  primarily  on  the  design  and  utility  of  the  user 
interface  to  automated  C ,  systems,  and  not  the  engineering  design  Issues 
related  to  the  actual  hardware  and  software  components  of  these  systems. 
The  immediate  objective  of  this  document  is  to  formalize  the  requirements  for 
simulating,  not  building,  the  user  interface  to  automated  systems. 

The  user  Interface  is  the  soldiers'  link  to  the  capabilities  and  func¬ 
tions  provided  by  the  Cr  system.  The  Interface  includes  the  system's  display 
of  both  text  and  graphic  battlefield  information,  and  the  display  features 
and  control  functions  available  to  the  user  for  inputting  and  *cceiving  ad¬ 
ditional  Cr  data.  The  design  guidelines  and  functional  specifications  pre¬ 
sented  in  this  report  are  based  on  (1)  formally  established  guidelines  for 
interface  design  taken  from  the  human  factors  literature,  and  (2)  the  users' 
current  estimate  of  their  interface  requirements  for  automated  C 3  systems. 

The  development  of  automated  systems  for  lower  echelon  units  is  an 
iterative  process  that  will  include  a  series  of  Preplanned  Product  Improve¬ 
ments  (P^I).  This  document  has  focused  on  the  guidelines  and  specifications 
required  for  simulating  the,  operational  capabilities  currently  anticipated 
for  BMS.  But  BMS,  in  fact,  is  not  expected  until  after  a  starter-set 
system,  currently  referred  to  as  the  Intervehicular  Information  System 
(IVIS) ,  has  been  successfully  fielded  and  tested.  Distinctions  between  IV1S 
and  BMS,  which  are  discussed  in  a  later  section,  might  be  summarized  by 
scribing  IVIS  a  a  degraded  version  of  BMS. 
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By  specifying  the  more  advanced  functions  associated  with  BMS,  rather 
than  IVIS,  a  prototype  automated  system  will  be  developed  using  simulation 
that  allows  researchers  to  investigate  related  human  performance  issues  in 
both  the  near  and  mid  term.  It  is  anticipated  that  human  performance  issues 
related  to  IVIS,  in  the  near  term,  can  be  addressed  by  a  graceful  degradation 
of  more  advanced  BMS  capabilities.  In  addition,  the  development  of  a  more 
capable  prototype  will  allow  the  Army  to  conduct  trade-off  analyses  directly 
comparing  the  utility  of  more  advanced  and  automated  systems. 


The  ultimate  objective  of  this  effort  is  to  initiate  the  development  of  a 
simulated  BMS  interface  that  can  be  rigorously  evaluated  and  modified  in  a 
task-loaded  environment  such  as  that  provided  by  a  simulation  network 
(SIMNET)  of  combat  weapon  systems.  SIMNET  is  a  technological  innovation 
sponsored  by  the  Defense  Advanced  Research  Projects  Agency  (DARPA)  that  sup¬ 
ports  distributed,  multi-player,  real-time  and  continuous  combat  gaming.  One 
version  of  SIMNET  is  called  Developmental  SIMNET,  SIMNET-D,  in  which  the 
simulator's  characteristics  are  configured  via  rack  mounted  displays  and 
controls  that  can  be  rapidly  modified  to  emulate  prototype  weapon  systems  or 
subsystems  along  with  their  associated  soldier-machine  interfaces. 

The  BMS  interface  described  in  this  document  will  be  developed  for 
SIMNET-D.  The  reconf igurable  nature  of  simulated  weapon  systems  in  SIMNET-D 
will  provide  a  medium  for  systematically  testing  and  refining  BMS  design 
features  and  operating  characteristics.  In  addition,  this  test  bed  will 
afford  a  medium  for  evaluating  CJ  systems  that  is  sufficiently  (1)  objective, 
given  the  automated  data  capture  capabilities  of  SIMNET  and  (2)  valid,  given 
SIMNET' s  potential  for  assessing  force-on- force  combat  effectiveness  as  a 
function  of  lower  echelon  command,  control  and  communication.  The  sol- 
dier-in-the-loop  nature  of  the  SIMNET  battlefield  Is  ideal  for  evaluating 
both  soldier  performance  Issues  and  BMS  related  training  requirements. 


DISPLAY  CONFIGURATION 


The  prototype  BMS  user  interface  must  provide  the  user  access  to  all  of 
the  automated  command,  control,  and  communication  functions  anticipated  for 
the  system,  and  serves  as  a  transparent  link  to  the  various  subsystems 
Interfaced  to  BMS.  The  overall  layout  and  configuration  of  the  proposed  BMS 
Interface  are  presented  in  Figure  1. 


As  noted  previously  the  focus  of  this  document  is  BMS,  an  advanced  proto¬ 
type  for  automated  C^,  rather  than  a  starter-set  system  such  as  IVIS.  As  a 
near  term  solution  to  automated  C^,  IVIS,  for  example,  is  not  expected  to 
provide  a  digital  terrain  data  base  with  its  associated  man-made  and  natural 
terrain  features  including  terrain  elevation  data  critical  to  tactical  issues 
of  cover,  concealment,  and  avenues  of  approach.  Instead,  the  IVIS  interface 
is  expected  to  display  a  grid  reference  matrix  as  depicted  in  Figure  2.  Re¬ 
lated  BMS  enhancements  not  anticipated  for  IVIS  include:  color  monitor; 
completely  integrated  vehicle  subsystems  (e.g.,  hull  and  turret  network 
boxes,  ballistics  computer  etc.);  artificial  intelligence  functions  for  ter¬ 
rain  analysis  and  mission  planning;  and  advanced  microprocessor  capabilities 
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for  more  efficient  and  integrated  storage,  processing  and  transmission  of 
command  and  control  information  across  all  elements  of  the  Maneuver  Force. 

Similarities  between  IYIS  and  BMS,  however,  with  respect  to  more  funda¬ 
mental  design  guidelines  and  specifications  are  reflected  by  a  comparison  of 
their  respective  figures.  The  reconf igurable  nature  of  SIMNET-D  prototypes 
will  support  ti^e  graceful  degradation  of  the  more  advanced  BMS  features  and 
functions  to  evaluate  IVIS  specific  issues  when  required.  With  this  under¬ 
standing,  the  remainder  of  this  document  will  address  BMS  guidelines  and 
specifications  and  IVIS  will  no  longer  be  discussed. 

As  depicted  in  Figure  1,  the  BMS  display  is  partitioned  into  seven  dis¬ 
tinct  sections.  Beginning  in  the  upper  left  hand  corner,  the  map  section  (a) 
of  the  display  depicts  a  bird’s-eye  view  of  the  battlefield  as  provided  by  a 
digital  terrain  data  map  of  the  area.  The  three  sections  depicted  at  the 
bottom  of  the  display  represent  a  series  of  dedicated  soft  switches  by 
which  the  user  Initiates  the  various  BMS  command,  control,  and  communication 
functions  or  annotates  the  map  display.  The  three  switches  on  the  left  of 
this  row  (b)  are  dedicated  report  and  alert  keys  that  allow  the  user  to  make 
easy,  rapid  inputs  for  each  of  the  following  critical  battlefield  data: 
contact  reports;  calls  for  indirect  artillery  fires;  and  nuclear,  biological, 
and  chemical  (NBC)  reports. 

In  the  next  section  (c),  and  to  the  right  of  the  dedicated  report  keys, 
are  a  series  of  controls  that  serve  as  main  menu  keys.  Activation  of  these 
keys  provides  the  user  access  to  a  series  of  submenus  for  the  following  dis¬ 
play  and  control  functions:  map  annotations  or  "tools"  for  controlling  the 
information  displayed  in  the  map  section;  status  menus  for  monitoring  and 
reporting  vehicle,  subsystem,  personnel  and  logistic  data;  report  functions 
for  communicating  both  textual  and  map-based  battlefield  data  central  to 
command  and  control;  a  radio  Interface  for  selecting  and  monitoring  communi¬ 
cation  networks  and  automating  call  signs  and  authentication  procedures;  and 
a  menu  for  updating  the  vehicle's  position  and  navigation  data. 

The  final  section  (d)  in  this  row  is  the  SEND  key  which  provides  the  user 
the  ability  to  transmit  digitally  BMS  related  command  and  control  informa¬ 
tion.  To  prevent  accidental  transmissions  the  activation  of  this  key  should 
require  a  unique  type  of  user  input  such  as  a  one  or  two  second  continuous 
entry. 

The  relatively  large  section  (e)  on  the  right  side  of  the  BMS  display  is 
the  variable  menu  area.  In  this  region  the  submenus,  selected  by  the  user's 
activation  of  the  main  menu  switches,  are  presented.  Depending  on  the  sub¬ 
menu  selected,  the  user  is  provided  a  series  of  options  for  monitoring, 
updating  or  reporting  command  and  control  data.  In  addition,  the  variable 
menu  area  provides  access  to  a  variety  of  map  functions  that  allow  the  user 
to  (1)  tailor  his  own  map  display  or  (2)  prepare  graphic  command  and  control 
measures  (i.e.,  operational  overlays)  for  subsequent  communications. 

The  section  (f)  immediately  above  this  variable  menu  area,  the  mes¬ 
sage/alert  section,  informs  the  user  that  incoming  reports,  orders,  warnings 
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or  other  information  are  waiting  to  be  received.  The  actual  contents  of 
these  messages  will  be  presented  in  the  variable  menu  and  map  sections  of  the 
BHS  display  once  the  user  has  requested  receipt  of  the  message  by  touching 
the  RECEIVE  key.  To  prevent  disruptions  and  ensure  reception,  users  have 
requested  that  incoming  messages  should  not  be  automatically  presented 
(Lickteig,  1986a).  The  RECEIVE  key  is  included  in  this  section  to  provide 
the  user  discrete  and  immediate  access  to  incoming  transmissions  upon  re¬ 
quest. 

The  section  (g)  in  the  upper  left  hand  corner  of  the  display,  date/time, 
provides  the  user  a  continuous  display  of  this  information.  The  RESET  key 
provides  the  user  access  to  a  manual  update  function  and  a  menu  for  selecting 
other  time  related  functions  upon  request  such  as  alpha  or  zulu  time  codes 
and  backward  planning  functions. 

In  addition  to  these  seven  primary  subsections  of  the  BMS  display,  two 
location  windows  are  required.  The  first  is  an  Own  Location/Heading  window 
that  displays  the  current  location  of  the  user  in  six-digit  coordinates 
(8-and  10-digit  options  included)  and  his  heading  in  three-digit  degrees  (mil 
option  included).  This  information  is  continuously  updated  by  the  Position 
Navigation  (POSNAV)  system  and  corresponds  to  the  position  of  the  vehicle  as 
depicted  on  the  BMS  display  (See  POSNAV  Functions).  This  window  is  located  in 
the  lower  left  corner  of  the  map  display.  The  second  lev  -ion  window  Is  a 
Point  Location  that  displays  the  six-digit  location  of  a..  ’screte  touch 
entry  made  on  the  map  display.  For  example,  with  the  ent  v  of  any  waypoint, 
control  measure,  or  touch  contact  with  the  map  display,  the  six-digit  coordi¬ 
nates  of  that  entry  should  be  displayed  in  the  Point  Location  window  which  Is 
located  in  lower  right  comer  of  the  BMS  map  display.  The  Point  Location 
window  might  only  appear  when  the  user  is  designating  a  location  (e.g.,  unit, 
measure,  point)  on  the  map  display.  In  Figures  1  and  2  it  is  designating  the 
location  of  the  enemy  tank  unit.  Finally,  Figure  3  is  included  to  provide 
the  reader  an  example  of  the  proposed  BMS  interface  at  the  currently 
projected  size,  9-Inch  diagonal. 

The  overall  configuration  of  the  BMS  display  partitioned  into  a  number  of 
sections  suggests  that  these  are  dedicated  partitions  which  are  permanently 
assigned  In  support  of  the  functions  described.  A  more  optimal  display  con¬ 
figuration,  however,  might  provide  the  option  to  temporarily  repartition  the 
display  depending  upon  current  activity  (Brown,  Burkelo,  Mangelsdorf,  Olsen, 

&  Williams,  1981;  Galitz,  1981)  and  to  automatically  remove  interim  data  from 
the  display  when  it  is  no  longer  needed  (Martin,  1973;  Newman  &  Sproull, 
1979).  For  example,  during  lulls  in  the  battle  such  as  preoperation  checks, 
initialization,  or  consolidation,  the  map  area  might  be  reduced  or  temporar¬ 
ily  exchanged  for  an  extended  reporting  area  in  the  variable  menu  section 
(see  Map  Functions).  This  would  reduce  the  layers  of  submenus  and  user  in¬ 
puts  required  for  more  extensive  reports.  Again,  the  soldier-in-the-loop 
nature  of  SIMNET  should  provide  an  excellent  medium  for  exploring  this  and 
other  interface  issues  and  refining  this  prototype  display. 
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Figure  3.  BMS  interface  at  approHimate  9-inch  diagonal  size. 


DISPLAY  GUIDELINES 


Design  Guidelines 

The  design  of  automated  information  management  systems  has  received  a 
great  deal  of  attention  during  the  past  decade,  an  interest  directly  related 
to  exponential  Increases  in  the  availability  and  applicability  of  personal, 
mini,  and  microcomputers.  This  attention  has  resulted  in  numerous  guide¬ 
lines  for  the  design  and  development  of  user-computer,  man-machine,  inter¬ 
faces  (Engel  &  Granada,  1975;  Galitz,  1981;  Pew  &  Rollins,  1975;  Ramsey  & 
Atwood,  1979;  Smith,  1981;  Smith  &  Hosier,  1984).  A  recent  edition  of  Human 
Factors  Review  (Muckier,  1984),  for  example,  includes  a  collection  of  reviews 
on  various  aspects  of  interface  design  such  as  visual  display  terminals, 
input  media  including  voice  technologies,  dialogue  modes  and  computer  as¬ 
sisted  instruction.  These  design  guidelines  provide  a  valuable  base  of  in¬ 
formation  when  designers  are  confronted  with  the  need  for  a  unique  Interface 
such  as  BMS  which  entails  multiple,  complex,  and  conflicting  design  require¬ 
ments  . 

Guidelines,  however,  are  generic — a  collection  of  recommendations  and 
caveats  abstracted  from  research  and  experience  with  various,  and  at  times 
differing,  interface  requirements.  The  designer  must  adapt  these 
prescriptions  to  the  unique  functions,  tasks,  users,  technologies,  costs, 
systems,  and  operational  environments  associated  with  the  Interface  being 
designed.  In  addition,  utilization  of  design  guidelines  generally  involves  a 
multidisciplinary  collaboration  between  the  users  who  define  the 
requirements,  human  factors  specialists  who  specify  an  Interface  design  that 
effectively  Integrates  those  requirements,  and  the  hardware  and  software 
engineers  who  actually  develop  the  Interface. 


U?er-B*sed  Guidelines 

While  the  specification  of  u&er  interface  designs  and  supporting  func¬ 
tions  accounts  for  30-35Z  of  all  applications  software  (Smith  &  Mosier, 

1984),  Interface  designers  rely  on  formally  developed  design  guidelines  in 
less  than  10Z  of  their  applications  (Klein  &  Brezovic,  1986;  Tijernia, 

1986).  The  designers  interviewed  by  Klein  and  Brezovic  stated  that  relevant 
design  guidelines  were  too  difficult  to  locate  in  the  technical  literature 
and  the  extrapolation  of  relevant  guidelines  from  irrelevant  data,  too  ques¬ 
tionable.  The  work  of  Klein  and  Brezovic,  Tijernia,  and  others  demonstrates 
that  most  designs  are  based  on  mock-up  or  prototype  interfaces  and  Informal 
assessments  (e.g.,  n  *  1)  or  quasi-experimentation.  The  designer's  prefer¬ 
ence  for  hands-on  tests,  given  the  difficulty  of  translating  basic  research 
Into  design  applications.  Is  not  only  defended — but  forcefully  advocated  by 
many  designers — as  in  Schell's  (1986)  recent  paper:  "Usability  Testing  of 
Screen  Design:  Beyond  Standards,  Principles,  and  Guidelines.” 

Similarly,  the  display  and  control  features  of  the  proposed  BMS  prototype 
are  based  on  the  user  Interface  requirements  for  BMS  that  have  been  previ¬ 
ously  identified  by  a  series  of  evaluations  conducted  by  the  Directorate  of 
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Combat  Developments  (DCD)  at  Fort  Knox  and  the  Army  Research  Institute  of 
Fort  Knox.  Prior  user  evaluations  of  prototype  BMS  displays  have  attempted 
preliminary  identification  of  the  BMS  informational  requirements  (Jobe, 

1986),  functional  requirements  (Lickteig,  1986a),  training  requirements 
(Lickteig,  1986b),  and  operational  requirements  (Blasche  and  Lickteig,  1984). 
The  BMS  interface  design  specified  in  this  document  has  incorporated  the 
user-based  requirements  of  this  earlier  work. 


Simulation  Guidelines 


The  following  set  of  guidelines  specify  the  design  guidelines  and  func¬ 
tional  specifications  of  the  BMS  interface,  and  particularly  the  BMS  display 
and  control  requirements.  Later  sections  are  organized  around  the  major 
functions  of  BMS  and  specify  the  menu  structure,  data  formats,  and  instruc¬ 
tional  prompts  required  for  users  to  execute  these  functions  via  the  BMS 
Interface.  This  section  documents  for  the  developers  the  formal  guidelines 
employed  in  design  of  the  BMS  interface,  and  reference  to  the  technical  docu¬ 
mentation  on  which  these  guidelines  are  based.  In  addition,  these  guidelines 
serve  as  a  designer's  template  for  addressing  any  BMS  Interface  functions  not 
directly  discussed  in  this  document  (e.g.,  new  or  unanticipated  BMS  func¬ 
tions). 

In  general,  the  design  of  the  BMS  interface  has  attempted  to  Incorporate 
the  general  human  factors  that  apply  to  all  man-machine  interfaces  Including 
computers:  consistency,  brevity,  flexibility,  immediate  feedback,  and  re¬ 
duced  operator  workload  (Vllliges  &  Williges,  1984).  In  their  article  on 
dialogue  modes,  Vllliges  and  Vllliges  (1984)  provide  a  comprehensive  review 
of  the  guidelines  currently  available  to  interface  designers.  To  extend  the 
standardization  of  Interface  design,  and  afford  the  developers  ready  access 
to  the  supporting  documentation,  the  following  guidelines  and  specifications 
for  simulation  of  a  BMS  prototype  are  organized  around  the  content  areas  and 
guidelines  provided  by  Vllliges  and  Vllliges. 


Display  Size 

The  size  of  the  BMS  display  panel  is  constrained  by  the  limited  space 
available  in  an  armored  vehicle  and  particularly  the  tank.  Prior  work  on  BMS 
interfaces  has  focused  on  a  7-  to  9-inch  diagonal  display.  User  evaluations, 
dependent  upon  the  contrast  and  resolution  of  display  prototypes  tested,  have 
favored  the  8-  to  9-inch  display.  It  is  anticipated  that  initially  SIMNET's 
BMS  display  screen  will  have  a  minimum  12-inch  screen  due  to  the  high  cost  of 
providing  a  smaller  screen  with  sufficient  resolution.  By  windowing  this 
12-inch  display  into  smaller  display  areas,  however,  a  reconfigurable  BMS 
interface  must  allow  for  the  assessment  of  alternative  display  sizes  (e.g., 
8-,  9-,  or  10-lnch  diagonal  display  surfaces). 

Specific  guidelines  are  not  readily  available  with  respect  to  variable 
display  sizes,  and  particularly,  the  limitations  inherent  to  small  screen 
displays.  An  assessment  clearly  echoed  by  the  title  of  a  recent  review  by 
Shannon  and  Stewart  (1986),  "Human  Performance  Aspects  of  Small  Screen  Dis- 
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plays:  A  Literature  Review  Revealing  the  Lack  of  Specific  Research."  The 
limited  display  size  of  BMS  is  a  driving  design  factor,  however,  and  so  the 
following  general  guidelines  are  provided.  Minimize  the  information  density 
by  presenting  only  information  essential  to  the  user  at  that  time  (Brown  et 
al.,  1981),  and  by  automatically  removing  interim  data  from  the  display  when 
it  is  no  longer  needed  (Hartin,  1973;  Newman  &  Sproull,  1979).  Users  must 
have  the  capability  to  remove  irrelevant  items  from  the  display  and  to  re¬ 
verse  these  decisions  (e.g.,  selected  deletion  and  call-up  of  terrain  fea¬ 
tures)  as  noted  by  Baraack  and  Sinaiko  (1966)  and  Ramsey  and  Atwood  (1979). 
Finally,  all  data  relevant  to  the  user's  current  task  should  be  displayed 
simultaneously  whenever  possible  (Galitz,  1981). 


Display  Location 

The  actual  location  of  the  BMS  interface  in  the  tank  is  currently 
unspecified.  An  operational  test  of  IVIS,  the  Engineer  Design  Test  by  the 
Contractor  (EIT-C),  evaluated  both  right-front  and  right-side  interface  loca¬ 
tions  the  ccneander's  weapon  station.  The  frontal  location  was  immedi¬ 
ately  right  ot  'iite-^nrer^s  primary  signt  extension  (GPSE),  and  the 
side-mounted  location  was  commander's  right  shoulder.  Formal  re¬ 

sults  of  the  EDT-C  have  not  been  released,-  bst  preliminary  data  suggest  that 
the  right-front  location  appeared  considerably  more  accessible  to  the  user 
far  both  extracting  visual  Information  from  the  display  and  inputting  user 
command  and  control  data.  Therefore,  a  right-front  location  adjacent  to  the 
GPJE  is  Initially  recommended  for  SIMNET's  BMS  Interface.  In  general, 
SDIWET-D's  reconfigurability  should  afford  an  excellent  test-bed  for  assess¬ 
ing  the  trade-offs  associated  with  alternative  locations  for  BMS  and  other 
tank  subsystem  components . 


Screen  Layout 

Standardized  locations  for  functional  areas  and  display  fields  are  speci¬ 
fied  for  the  BMS  Interface  and  correspond  to  the  seven  distinct  subsections 
depicted  In  Figure  1.  A  summary  of  the  screen  layout  guidelines  Incorporated 
into  tbs  proposed  BMS  interface  Is  provided  In  Table  1.  Rationales  for  these 
guidelines  are  presented  below  with  reference  to  their  documentation  in  the 
human  factors  literature.  In  general,  all  the  BMS  functional  areas  must  re¬ 
main  in  the  same  location  on  all  frames  to  allow  users  to  develop  spatial 
expectancies  and  a  perceptual  model  of  the  operating  system  (Brown  et  al., 
1981;  Engel  &  Granada,  1975;  Galitz,  1981;  Parrish,  Gates,  Munger,  & 

Sidorsky,  1981).  Data  entry  dialogues  are  initiated  in  the  upper  left  corner 
of  the  variable  aenu  partition  (Galitz,  1981),  and  main  function  keys  or 
commands  are  located  at  the  bottom  of  the  display  (Smith,  1981).  Each  dis¬ 
play  page  appearing  in  the  variable  menu  area  is  titled  to  Indicate  the  pur¬ 
pose  of  the  page  (Pew  &  Rollins,  1975),  instructional  prompts  are  highlighted 
(Brown  et  al.,  1981;  Martin,  1973),  and  these  prompts  precede  the  list  of  re¬ 
sponse  options  (Brown  et  al.,  1981;  Engel  &  Granada,  1975;  Galitz,  1981). 
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Table  1 


Screen  Layout  Guidelines 


Standardized  location — develop  user  expectancies,  develop  perceptual  model  of 
the  Interface. 

Data  entry  dialogues  initiated  in  the  upper  left  of  variable  menu 
area. 

Main  function  keys  or  commands  located  at  the  bottom  of  the  display. 

Each  display  page  titled. 

Instructional  prompts  highlighted. 

Prompts  precede  the  list  of  response  options. 


Color  Codes 


Guidelines  for  implementing  color  codes  in  the  prototype  interface  are 
summarized  in  Table  2.  Conventional  military  color  coding  shall  be  used 
whenever  possible  in  the  design  of  BMS  display  features  such  as  friendly  and 
threat  units,  topographic  map  features,  and  tactical  control  measures.  In¬ 
formation  should  not  be  coded  solely  on  the  basis  of  color,  however,  since 
monochromatic  displays  and  printers  may  be  employed  in  some  instances. 

In  general,  color  coding  for  the  BMS  Interface  is  specified  to  direct 
user  attention  to  headings,  input  errors,  data  requiring  immediate  attention, 
key  data  Items,  differentiated  data  groups,  and  particularly,  items  embedded 
in  search  tasks  (Brown  et  al.,  1981;  Galltz,  1981;  Ramsey  &  Atwood  1979; 
Uilllges  8  Vllllges,  1984).  No  more  than  10  color  codes  or  more  than  three 
hues  are  recommended  (Engel  &  Granada,  1975;  Ramsey  &  Atwood,  1979),  and 
green  might  serve  as  the  primary  color  used  in  the  BMS  display,  with  red  and 
blue  used  sparingly  (Brown  et  al.,  1981).  The  definition  or  label  for  a 
colored  object  should  be  provided  in  a  hue  of  the  same  color,  and  user  inputs 
should  be  colored  in  turquoise  or  cyan  (Brown  et  al.,  1981). 


Table  2 

Color  Coding  Guidelines 


Conventional  military  color  coding — FM  101-5-1;  FC  71-6;  FC  17-17. 

Direct  user  attention  to  headings,  input  errors,  data  requiring  immediate 
attention,  key  data  items,  differentiated  data  groups  of  data  and 
particularly  for  search  tasks. 

10  color  codes,  3  hues  max. 

Information  should  not  be  coded  solely  on  basis  of  color. 

Green,  primary  color;  red  and  blue  used  sparingly. 

Cyan  or  turquoise  for  user  inputs. 
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Table  3 


Blinking  Code  Guidelines 


Blink  codes  are  specified  for  alarms,  target,  and  object  detection 
tasks — particularly  on  the  map  display. 

2-  to  3-Hz  cycle  with  a  minimum  duration  of  80  ms  for  urgent  item. 
3  blink  codes  maximum  (static,  slow  and  fast). 

Blinking  terminates  when  user  has  responded. 

Blink  codes  could  be  made  adjustable  to  the  users  scan  rate. 


Blinking  Codes 

Blink  codes  are  specified  for  BMS  alarms  and  object  detection  tasks 
(Parrish  et  al.,  1981;  Ramsey  &  Atwood,  1979),  particularly  on  the  map  dis¬ 
play  area.  More  urgent  warnings  and  alerts  should  be  blink  coded  on  a  2-  to 
3-Hz  cycle  with  a  minimum  duration  of  80  ms  (Ramsey  &  Atwood,  1979).  No  more 
than  three  blink  codes  (static,  slow,  and  fast)  should  be  used  (Barmack  & 
Sinaiko,  1966;  Engel  &  Granada,  1975)  and  blinking  should  be  turned  off  when 
the  user  has  responded  (Galitz,  1981).  Blink  codes  could  be  made  adjustable 
to  the  users  scan  rate  (Ramsey  &  Atwood,  1979).  Designer  guidelines  for  di¬ 
recting  user  attention  via  blinking  codes  are  presented  in  Table  3. 


Auditory  Codes 

Auditory  signals  should  be  used  to  alert  and  direct  the  users'  attention 
to  the  appropriate  areas  of  the  display  interface.  Auditory  signals  should 
be  provided  as  an  auxiliary  indication  of  incoming  messages,  alerts  and  warn¬ 
ings.  The  number  of  auditory  codes  used  for  signaling  incoming  information 
should  be  kept  to  a  minimum  and  serve  primarily  to  distinguish  between  criti¬ 
cal  and  non-critlcal  communications.  Auditory  signals  should  also  be  in¬ 
cluded  to  alert  the  user  to  system  failures.  While  exact  specification  of 
the  auditory  codes  to  be  used  in  the  prototype  are  not  provided,  the  realis¬ 
tic  sound  effects  included  in  SIMNET  provide  the  opportunity  to  evaluate 
differential  coding  patterns  that  may  prove  effective  in  subsequently 
fielded  systems.  In  general,  the  designers  are  reminded  that  the  optimum 
signal  should  alert  the  user,  but  not  interfere  with  ongoing  task  require¬ 
ments.  In  addition,  the  signal  should  be  adjustable  with  respect  to  variable 
background  noises,  intermittent  in  nature  to  allow  the  user  time  to  respond, 
and  the  user  should  be  able  to  terminate  non-critical  signals  at  his  discre¬ 
tion  and  in  the  Interest  of  operational  security  (Hendricks,  Kilduff,  Brooks, 
Marshak  and  Doyle,  1983). 


Highlighting 

Brightness  codes  are  specified  for  highlighting  the  single  or  next  item 
on  the  display  that  required  the  user's  attention  or  response  (Engel  & 
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Table  4 


Highlighting  Code  Guidelines 


Direct  user  to  single  or  next  item  on  the  display  that  requires  the  users' 
attention  and/or  response. 

10%  maximum  of  the  display  highlighted  at  anytime. 

3  levels  maximum  of  brightness  coding. 

Reverse  video  is  specified  for  highlighting  textual  data. 


Granada,  1975).  No  more  than  10%  of  the  BHS  display  should  be  highlighted  at 
any  time  (Parrish  et  al.,  1981)  and  no  more  than  three  levels  of  brightness 
coding  should  be  used  (Engel  &  Granada,  1975;  Galitz,  1981).  Reverse  video 
is  specified  for  highlighting  textual  data  (Engel  &  Granada,  1975). 


Dialogue  Mode 


A  menu- select ion  dialogue  mode  is  specified  for  BMS  and  detailed  in  the 
following  sections.  Rationale  for  the  menu-selection  dialogue  (See  Table  5) 
was  based  primarily  on:  the  need  to  minimize  training  time  and  user 
difficulties  (Galitz,  1981;  Parrish  et  al.,  1981);  the  potential  for  new 
users  (e.g.,  attrition,  mobilization)  who  are  unfamiliar  with  the  BMS  func¬ 
tions  (Parrish  et  al.,  1981);  and,  to  support  BMS’s  primary  task  of 
automating  the  fixed  procedures  and  routine  tasks  required  for  command,  con¬ 
trol,  and  communication  (Miller  &  Thomas,  1976;  Smith,  1981).  In  addition, 
menu  items  and  response  options  such  as  units  and  control  measures  should  be 
depicted  graphically  whenever  possible  (Foley,  Wallace,  &  Chan,  1981;  Newman 
&  Sproull ,  1979). 


Table  5 

Rationale  for  Menu  Dialogue  Mode 


Need  to  minimize  training  time  and  user  difficulties. 

Potential  for  new  users  (e.g.,  attrition,  mobilization)  unfamiliar  with  the 
system. 

Need  to  automate  fixed  procedures  and  routine  tasks. 

Initial  entry  accuracy  Is  critical. 

Selection  of  graphic  Icons  (unit  and  control  measures)  and 
multiple  colors. 
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Table  6 


Menu  Layout  Guidelines 


Menu  location  standardized. 

Each  menu  frame  presents  a  list  of  selectable  items  or  responses  and  an  ENTER 
key  for  inputing  the  item  selected. 

Lists  of  menu  items  brief,  arrange  in  separate  columns,  aligned  and 
left-justified. 

Multi-page  option  lists  avoid  whenever  possible. 

If  multi-page  option  list  is  required,  users  able  to  tailor  the  lists  (e.g., 
INITIALIZATION  procedures  for  unit  and  control  measure  symbology). 
Highlight  most  likely  response  option. 

Control  options  available  at  any  step. 


Menu  Layout 

Menu  layout  is  a  particularly  important  aspect  of  this  implementation 
because  of  the  interface's  small  display  area.  Guidelines  for  menu  layout 
are  summarized  in  Table  6.  Each  menu  frame  for  the  BMS  interface  must  pres¬ 
ent  a  list  of  selectable  items  or  responses  and  an  ENTER  key  for  inputting 
the  Item  selected  (Engel  &  Granada,  1975;  Smith,  1981).  When  the  list  of 
menu  items  is  brief  they  must  be  arranged  in  separate  columns  (Pew  &  Rollins, 
1975)  and  these  columns  aligned  and  lef t-justified  (Galitz,  1981).  When  the 
list  of  options  required  for  completing  a  report  are  not  brief,  the  design 
may  Include  multiple  "pages,"  sequentially  displayed  report  options. 
Multi-page  option  lists  should  be  avoided  whenever  possible  (Engel  &  Granada, 
1975;  Parrish  et  al.,  1981;  Pew  &  Rollins,  1975).  When  multi-page  option 
lists  are  required,  users  must  be  allowed  to  preselect  the  options  appearing 
on  the  first  and  subsequent  pages  (see  specifications  of  INITIALIZATION  pro¬ 
cedures  for  unit  and  control  measure  symbology). 

Menu  location  is  standardized  in  the  variable  menu  window  and  in  the  case 
of  cursor  entry,  the  cursor  must  align  automatically  on  the  most  likely  re¬ 
sponse  option  (Smith,  1981).  Control  options  that  are  generally  available 
at  any  step  (e.g.,  SEND,  RESET,  and  other  dedicated  functions)  are  input  by 
special  functions  keys  (Smith,  1981).  One  design  shortcoming  of  the  proposed 
BMS  menu  layouts  Is  that  they  do  not  yet  include  overviews  (e.g.,  wiring 
diagrams)  that  show  the  user  his  current  location  within  a  hierarchical  menu 
structure  (Smith,  1981). 


Data  Format 


The  standardized  data  formats  of  the  military  (i.e.,  EM  101-5-1  Opera¬ 
tional  Terms,  Graphics  and  Symbology;  71-6  Battalion/Brigade  Command  and 
Control,  1  March  1985;  FC  17-17,  The  Division  86  Tank  Battalion/Task  Force 
SOP,  Coordinating  Draft,  July  1983;  FC  17-16,  The  Division  86  Tank  Company 
SOP  Coordinating  Draft,  May  1983;  and  FC  17-15-3,  Tank  Platoon  SOP,  April 
1985)  are  specified  for  the  BMS  prototype  whenever  applicable.  This  document 
attempts  to  provide  developers  reference  to  these  military  standards  as 
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Table  7 


Data  Format  Guidelines 


Military  standardized  data  formats — FM  101-5-1;  FC  71-6;  FC  17-17. 
Critical  information  requirements  under  system,  not  user,  control. 

Data  entries  limited  to  8-10  characters,  or  partitioned  into  smaller  sub¬ 
groups. 

User  input  and  system  output  formats  same  or  very  similar. 


specific  data  formats  are  described  in  subsequent  sections  (e.g.,  unit  and 
control  measure  symbology,  report  formats  etc.).  The  format  for  critical  in¬ 
formation  requirements  should  generally  be  under  system,  not  user,  control 
to  ensure  standardization  (Engel  &  Granada,  1975).  Data  entries  should  be  no 
more  than  8  to  10  characters,  or  partitioned  into  small  subgroups  such  as  the 
grid  coordinate  formats  specified  under  POSNAV  functions  (Galitz,  1981; 

Smith,  1981).  Data  formats  for  user  inputs  and  system  outputs  should  be  the 
same  or  very  similar  (Smith,  1981).  More  general  recommendations  for  both 
text  and  numeric  data  are  summarized  by  Williges  &  Williges  (1984). 


Input  Devices 

Directing  or  pointing  controls,  rather  than  cursor  controls,  are  speci¬ 
fied  as  the  primary  input  device  for  BMS  (See  Table  8).  More  specifically,  a 
touch  panel  is  specified  over  a  light  pen  device.  These  specifications  arc 
consistent  with  recommendations  that  pointing  control  be  used  when  item  se¬ 
lection  and  position  designation  are  the  primary  types  of  data  entry  (Engel  & 
Granada,  1975;  Ramsey  6  Atwood,  1979;  Smith,  1981)  which  Is  clearly  the  case 
with  BMS.  Pointing  controls  are  also  highly  recommended  when  the  user-com¬ 
puter  dialogue  is  menu-based  (Foley  et  al.,  1981). 

For  precise  positioning,  touch  inputs  must  be  reflected  by  a  point  desig¬ 
nation  feature  (Engel  &  Granada,  1975;  Smith,  1981)  and  users  must  be  pro¬ 
vided  a  fine  resolution  mode  (see  PINPOINT  function  under  POSNAV)  or  the 

I 


Table  8 

Touch  Input  Guidelines 


Pointing  controls  recommended  when  item  selection  and  position  designation 
primary  types  of  data  entry,  and  user-computer  dialogue  is  menu-based. 
Touch  Inputs  reflected  by  a  point  designation  feature. 

Fine  resolution  mode  or  the  ability  to  rapidly  change  the  scale. 

System  entry  of  user  designated  points  and  locations  must  require  a  distinct 
user  action  such  as  activation  of  the  ENTER  key. 
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ability  to  rapidly  change  the  scale  of  the  map  or  graphic  (Engel  &  Granada, 

1975;  Foley,  Wallace,  &  Chan,  1981).  Actual  entry  of  user  designated  points 

and  locations  must  require  a  distinct  user  action  such  as  activation  of  the 

ENTER  key  (Smith,  1981).  User  evaluations  by  DCD  and  ARI  identified  that 

users'  prefer  a  touch-sensitive  input  device  which  is  specified  as  the  pri¬ 
mary  dev ica  for  BMS  in  SIMNET-D.  The  touch-sensitive  input  device  should  be 
augmented  by  track  ball  and  mo”se  devices  to  assess  the  differential  effects 
of  alternative  input  devices. 

Voice  inputs  requiring  voice  analyzers  would  appear  to  be  an  excellent 
candidate  for  the  input  device  if  the  technology  were  sufficiently  advanced 
for  Armor  application.  In  the  BMS  setting,  voice  input  is  desirable  since 
the  users'  hands  and  eyes  are  already  occupied  (Parrish,  Gates,  Munger,  & 
Sidorsky,  1981).  In  addition,  voice  analyzers  might  provide  automatic  iden¬ 
tification  and  verification  of  the  user  (Foley  et  al.,  1981)  that  would  en¬ 
hance  communication  security,  reduce  transmission  times,  and  decrease  the 
users'  workload.  When  these  technologies  have  sufficiently  matured  they 
should  be  developed  and  evaluated  as  an  alternative  BMS  input  device. 


Response  Options 

When  a  list  of  response  options  are  made  available  to  the  user  the  list 
should  be  arranged  in  a  logical  order  that  minimizes  search  and  response  time 
(Foley  et  al.,  1981;  Pew  &  Rollins,  1975;  Smith,  1981).  In  general,  the 
order  of  multiple  response  options  must  include  consideration  of  the  follow¬ 
ing  factors:  information  criticality;  standard  operating  procedures  (SOPs); 
frequency  of  utilization  or  appearance  (Engel  &  Granada,  1975;  Pew  &  Rollins, 
1975);  and  in  the  case  of  extended  selection  lists  and  noncritical  response 
times,  alphabetical  order  (Engel  &  Granada,  1975;  Galitz,  1981). 


Display  Functions 

One  of  the  primary  functions  of  BMS  is  to  provide  users  an  alternative  to 
the  paper  military  map.  Conventional  map  presentations  are  inflexible  * 
highly  codified  and  relatively  static  representations  of  a  small  surface  area 
of  the  earth  (Rogers  and  Cross,  1979).  These  limitations  are  compounded  by 
the  dynamic  requirements  for  terrain  analysis,  navigation,  and  maneuver  com¬ 
mand  and  control  In  the  Armor  battlefield  environment.  Conventional  proce¬ 
dures  for  annotating  or  updating  map  surfaces  with  the  operational  overlays 
required  for  tactical  combat  and  planning  are  time-consuming  and  demanding. 
Conventional  procedures  for  communicating  this  overlay  information  are  prone 
to  error  and  frequently  require  face-to-face  exchanges  in  an  unprotected 
setting. 

In  contrast,  BMS  provides  users  an  electronic  map  derived  from  a  digital 
terrain  data  base.  This  map  can  be  readily  tailored  to  the  immediate  area 
and  situational  requirements  of  the  user.  In  addition,  the  BMS  map  can  be 
overlayed  with  any  combination  of  unit  and  control  measure  symbology,  and 


15 


these  overlays  can  be  generated  or  updated  by  individual  users.  Map  and 
overlay  information  in  digital  format  can  be  more  rapidly,  securely,  and 
accurately  transmitted  to  other  BMS  users  and  operators. 

A  primary  consideration  in  the  design  of  these  BMS  functions  is  to  pro¬ 
vide  combat  commanders  a  simple  but  powerful  technology  for  automating  many 
of  their  command  and  control  functions.  To  ensure  that  the  system  is  both 
simple  and  powerful  with  respect  to  the  need  of  multiple  users,  from  the 
battalion  commander  down  to  the  individual  tank  commanders,  and  both  experi¬ 
enced  and  inexperienced  personnel  (e.g.,  attrition,  rapid  mobilization),  a 
major  design  principle  incorporated  into  BMS  is  the  user's  ability  to  tailor 
the  system  to  his  level  of  understanding  and  requirements.  The  ability  of 
the  user  to  scale  the  electronic  map  to  his  immediate  areas  of  interest  and 
influence,  for  example,  is  a  more  obvious  instance  of  tailoring. 

The  following  section  describes  the  variety  of  map  functions  and  their 
supporting  display  and  control  features  specified  for  the  BMS  prototype  in 
SIMNET-D.  Each  of  these  functions  are  accessed  through  a  series  of  submenus 
presented  in  response  to  user  activation  of  the  dedicated  MAP  key.  All 
map-based  reports  transmitted  by  BMS  are  automatically  stamped  with  the  time 
and  date  of  transmission  as  well  as  the  ID  and  position  of  the  reporting 
vehicle  and  the  user. 


Map  Key 


Upon  user  activation  of  the  MAP  key,  the  Map  Functions  submenu  appears  in 
the  variable  menu  section  of  the  BMS  display.  Figure  4  depicts  this  submenu 
and  the  list  of  map  functions  available  to  the  user.  Functions  are  listed 
alphabetically  to  facilitate  the  user’s  search  among  the  relatively  extensive 
set  of  map  functions  available.  In  addition,  the  Figure  includes  a  prompt 
describing  the  required  user  inputs.  The  user  selects  a  function  by  touching 
the  function  label  and  reverse  video  echoes  this  selection  for  user  verifica¬ 
tion.  The  user  inputs  the  selected  function  by  touching  the  ENTER  key  and 
the  system  automatically  accesses  that  function's  supporting  submenu.  Each  of 
these  map  functions  is  supported  by  various  submenus  which  are  described 
below. 

It  is  noted  that  later  generation  BMS  systems  are  expected  to  provide  a 
more  comprehensive  and  integrated  set  of  functions  for  map  utilization,  and 
detailed  terrain  analysis  in  particular.  The  intent  of  the  current  effort  is 
to  specify  a  set  of  functions  that  meet  the  primary  tactical  requirements  of 
the  maneuver  force  at  present,  and  at  the  same  time  develop  the  underlying 
tools  and  functions  that  will  be  needed  for  future  systems.  For  example,  the 
Route  Selection,  Distance,  Line-of-Sight  and  Relief  functions  described  below 
will  be  Integrated  in  a  more  advanced  system  that  automatically  calculates, 
compares,  and  selects  an  optimal  military  route  (Harris,  Fuller,  Dyck  and 
Rogers,  1985).  Given  the  user's  designation  of  the  area  to  be  traversed  or 
navigated,  more  advanced  systems  will  automatically  analyze  the  relative 
distance,  cover  and  concealment,  traf f icability,  and  logistics  to  select  and 
depict  the  most  tactically  advantageous  route. 
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MAP 


MAP  FUNCTIONS 


‘SELECT  ANY  FUNCTION, 
THEN  TOUCH  "ENTER"* 
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ENTER 


Figure  4.  Map  functions. 


Figure  5.  Distance. 
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Distance 


This  menu  provides  the  user  a  function  for  automatically  calculating  the 
distance  between  any  series  of  points  selected  on  the  map  (see  Figure  5). 

This  prototype  system  shall  require  that  for  other  than  straight  line  calcu¬ 
lations,  the  user  must  specify  the  route  based  on  his  analysis  of  the  terrain 
and  other  tactical  contingencies  of  interest.  To  determine  the  distance  of  a 
route  the  user  must  be  able  to  trace  out  the  actual  course  of  the  route  onto 
the  map  display,  or  designate  a  series  of  points  such  as  checkpoints  which 
represent  "legs"  or  segments  of  the  route. 


Draw 


The  Draw  Function  is  provided  as  a  backup  function  for  annotating  the 
user's  map  display.  The  use  of  predrawn  graphics  and  standard  military  sym¬ 
bology  such  as  control  measures  and  units,  as  discussed  below,  is  recommended 
whenever  possible  to  ensure  uniformity  and  intelligibility  of  the  communica¬ 
tions  and  to  minimize  the  processing  requirements  of  the  system.  At  present, 
precise  specifications  of  the  free  draw  capabilities  are  dependent  upon  final 
selection  of  input  devices  and  resolution  of  the  interface,  as  previously 
discussed  under  general  operating  characteristics  of  BMS. 

The  Draw  Function  provides  the  user  the  capability  to  annotate  his  map  in 
a  free  draw  manner.  The  menu  (see  Figure  6)  first  provides  a  small  palette 
of  colors  from  which  to  select  and  then  prompts  the  user  to  trace  an  outline 
of  the  object  on  the  map  display  surface.  Once  the  user  is  satisfied  with 
the  shape  and  location  of  the  object  drawn,  the  object  is  input  into  the 
system  by  activation  of  the  ENTER  key.  The  user  is  then  automatically  pro¬ 
vided,  as  indicated  by  reverse  lighting,  an  option  to  name  or  label  the  ob¬ 
ject  by  calling  up  a  soft  switch  keyboard  through  activation  of  the  TYPE  key. 
This  "keyboard"  may  require  at  least  partial  utilization  of  the  map  display 
area.  Utilization  of  this  map  area  must  not  occlude  the  object  being 
labelled.  After  typing  in  the  label  for  the  object,  the  user  again  activates 
the  ENTER  key  and  the  label  is  positioned  on  the  map  display  adjacent  to  the 
object  in  accordance  with  the  format  specifications  of  FM  101-5-1.  The  DE¬ 
LETE  key  allows  the  user  to  erase  or  remove  any  unwanted  objects  along  with 
their  respective  labels  from  the  map  display. 


Features 


This  submenu  provides  the  user  a  list  of  the  various  man-made  and  natural 
terrain  features  (see  Figure  7)  available  on  the  digitized  terrain  data  base. 
As  suggested  by  the  prompt,  the  user  may  call  up  any  combination  of  these  map 
features  and  the  selections  activated  are  again  highlighted  with  reverse 
video.  This  selective  call-up  will  allow  users  the  capability  to  tailor 
their  own  maps  and  facilitate  search  of  the  map  area  for  selected  features. 
The  capability  for  selective  call-up  of  only  the  features  of  immediate  inter¬ 
est  is  required.  The  capability  to  declutter  the  map  display  to  a  minimal 
subset  of  task-relevant  features  is  essential  to  ensure  that  users  are  not 
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Figure  6.  Free  draw. 
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Figure  7.  Terrain  features. 


overloaded  with  extraneous  detail,  particularly  during  the  more  intense 
phases  of  operation  and  engagement. 


Llne-of-Sight 

This  menu  provides  the  user  a  capability  to  visualize  the 
intervisibility,  the  ability  to  see  one  point  on  the  ground  from  another 
point  on  the  ground,  within  any  area  of  the  digital  terrain  data  base.  This 
is  an  extremely  important  function  with  respect  to  direct  fire  capability  and 
concealment,  and  one  of  the  most  laborious  and  complex  tasks  required  for 
terrain  visualization  and  tactical  planning.  For  prototype  implementation, 
line-of-sight  calculations  will  be  limited  to  terrain  and  vegetation  relief 
and  not  include  time  of  day,  weather,  or  other  obscurants.  The  line-of-sight 
calculations  will  be  of  three  types  as  depicted  in  Figure  8:  point-to-point, 
area,  and  continuous  area  updates. 

The  point-to-point  function  provides  the  user  a  limited  sector  of 
intervisibility  which  originates  from  the  first  location  designated  on  the 
map  display  (e.g.,  own  or  other  vehicle,  point  on  the  ground)  and  spreads  to 
the  second  location  designated.  While  this  sector  provides  a  more  limited 
perspective  than  that  provided  by  the  area  function  it  also  requires  less 
processing  by  the  system  and  allows  for  more  rapid  and  detailed  line-of-sight 
calculations. 

The  area  function,  on  the  other  hand,  provides  the  user  a  360  degree 
intervisibility  graphic  from  any  point  first  designated  on  the  map  display 
extending  to  the  radia  (range)  indicated  by  the  second  point  designated  by 
the  user.  In  addition,  the  line-of-sight  area  function  has  a  continuous 
update  capability.  For  example,  assuming  that  the  user’s  moving  vehicle  is 
the  central  point  of  interest  for  intervisibility,  the  continuous  mode  auto¬ 
matically  updates  the  line-of-sight  calculations  and  displays  the 
intervisibility  graphic  as  a  function  of  vehicle  movement  (e.g.,  every  100 
meters).  This  continuous  update  of  the  area  intervisibility  should  provide 
commanders  a  significant  tactical  advantage  for  maximizing  cover  and  conceal¬ 
ment  during  combat  maneuvers. 


Measures 


This  function  provides  the  user  relatively  direct  access  to  predrawn  and 
standardized  operational  graphics  for  tactical  annotations  to  the  map  dis¬ 
play.  The  set  of  control  measures  Included  under  this  function  and  the  sym¬ 
bology  for  these  measures  are  again  defined  by  FM  101-5-1  and  are  the  same  as 
those  used  for  the  Overlay  Function  which  is  described  below.  The  Measures 
Function,  however,  provides  the  user  more  immediate  and  direct  access  to 
required  elements  of  military  symbology.  The  function  is  designed  to  support 
more  timely  and  discrete  communications  such  as  extemporaneous  operational 
plans  (e.g.,  FRAGO) .  In  contrast,  the  Overlay  Function  is  designed  as  a  more 
complete  and  integrated  graphics  package  for  more  extensive  planning  require¬ 
ments  (e.g.,  OPORDs). 
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Figure  8.  Line  of  sight. 
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Figure  9.  Measures. 


Standard  data  formats  for  small  unit  command  and  control  requirements  are 
71-6  Battalion/Brigade  Command  and  Control,  1  March  1985  and  FC  17-17  The 
Division  86  Tank  Battalion/Task  Force  SOP,  Coordinating  Draft,  July  1983. 

The  FC  17-17  document  provides  a  definitive  reference  for  the  data  elements 
and  formats  required  for  measures  and  overlays  including  a  breakout  of  the 
measures  and  color  codes  associated  with  each  of  the  different  overlays: 
Personnel  (Red)  Intelligence  (Green),  Logistics  (Yellow),  Operations  (Blue) 
as  well  as  Shell  and  NBC.  Both  predrawn  symbology  and  free  draw  graphics 
created  by  the  users  must  be  displayed  and  stored  in  the  colors  appropriate 
to  the  o?erlays  being  developed. 

As  noted  In  the  discussion  of  general  BMS  functional  specifications,  the 
design  for  the  Measures  Function  was  based  on  the  trade-offs  between  the 
relatively  limited  area  available  on  the  BMS  display  for  report  and  message 
menus  and  the  need  for  simple,  rapid  access  to  graphic  functions  that  are 
critical  to  these  military  communications.  This  function  provides  the  user 
access  to  the  entire  index  of  military  symbology  Included  in  FM  101-5-1,  but 
requires  the  user  to  preselect  u  subset  of  these  symbols  for  each  of  the 
control  measure  categories  depicted  in  Figure  9.  The  user's  preselection 
specifies  the  particular  set  of  cootrol  measures  to  be  presented  In  the 
variable  menu  display  region  upon  activation  of  a  control  measure  category. 
The  user's  preselection  will  be  at  least  partially  based  on  his  duty  position 
and  anticipated  operations  in  support  of  the  mission. 

Access  to  the  Pi  101-5-1  dictionary  of  control  measure  symbology  and  the 
preselection  process  are  initiated  by  pressing  the  INITIALIZATION  key  dis¬ 
played  in  Figure  9.  While  complete  specification  of  the  initialization  proc¬ 
ess  and  supporting  menu  structures  are  beyond  the  scope  of  thlB  document,  it 
is  noted  that  this  Initialization  is  expected  to  occur  prior  to  actual  combat 
operations  as  part  of  the  commander's  weapon  station  preparation.  Given  this 
preope rational  status,  the  map  display  region  will  be  temporarily  transformed 
to  an  extended  dictionary  display  region  to  allow  the  user  to  readily  search 
and  select  from  the  dictionary's  contents. 

As  with  all  user  inputs,  range  control  fields  will  automatically  notify 
the  user  of  input  values  that  exceed  any  anticipated  boundaries  (e.g.,  dis¬ 
play  areas  for  variable  menu  and/or  map  display).  For  this  pre-selection 
process  for  example,  the  system  will  notify  the  user  when  the  number  of  con¬ 
trol  measures  selected  (e.g.,  6-10  measures)  exceeds  the  Immediate  menu  area 
available  to  the  system.  The  user  will  then  have  the  option  of  adding  or 
deleting  any  measures  to  this  primary  subset,  followed  by  the  option  to  se¬ 
lect  a  secondary  subset,  and  any  additional  subsets  required.  The  user's 
preselections  are  then  permanently  stored  until  reinitialization  is  re¬ 
quested.  In  addition,  the  system  should  have  the  capability  to  provide  de¬ 
fault  selections  for  each  category  of  control  measures  by  lower  echelon  duty 
positions. 

The  user's  activation  of  the  Measures  key  from  the  Map  Functions  menu 
(Figure  4)  immediately  accesses  the  list  of  control  measure  types  depicted  in 
Figure  9.  Selection  and  entry  of  one  of  these  types  of  measures  leads  di¬ 
rectly  to  a  submenu  of  the  various  measures  requested.  The  set  of  control 
measures  appearing  under  this  category  corresponds  to  those  preselected  by 
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the  user  daring  the  initialization  process  (or  default  values  provided  for 
the  doty  position  of  the  user).  The  subaenu  of  Lines,  Points,  and  Boundaries 
(see  Figure  10),  for  example,  provides  the  user's  preselected  control  meas¬ 
ures  for  this  category  such  as  platoon,  company,  and  battalion  boundary  meas¬ 
ures  and  several  instructional  prompts  about  how  to  superimpose  these 
■easures  onto  the  user's  up  display. 

As  indicated  by  the  instructional  prompts,  the  user  first  selects  the 
particular  control  unsure  required,  with  his  selection  being  reflected  by 
reverse  video  of  that  uasure  in  the  variable  menu  area,  and  then  touches  the 
up  display  at  the  locatlon(s)  the  measure  is  needed.  A  blinking  graphic  of 
the  measure  appears  at  that  location  and  the  six  digit  location  of  the  meas¬ 
ure's  center  appears  in  the  Point  Location  window.  For  measures  requiring 
sore  than  one  localization  point,  such  as  phase  lines  and  boundaries,  the 
system  verifies  input  of  the  first  point  with  a  blinking  cursor  and  awaits 
input  of  the  reulning  points  before  depicting  a  blinking  graphic  of  th^ 
measure  selected.  If  the  user  is  satisfied  with  this  location,  the  measure 
is  then  input  into  the  data  base  by  pressing  the  ENTER  key  at  which  time  the 
graphic  of  the  uasure  stops  blinking. 

As  Indicated  by  the  next  prompt,  the  user  can  change  the  orientation  of 
the  measure,  the  system's  default  orientation  is  North,  by  retouching  the  map 
in  the  direction  desired,  and  the  system  verifies  this  request  by  immediately 
realigning  the  blinking  icon  of  the  uasure  in  the  direction  indicated.  If 
the  user  is  satisfied  with  the  orientation,  retouching  the  up  will  re¬ 
peatedly  change  the  orientation.  When  satisfied  with  orientation,  the  user 
inputs  the  measure's  orientation  by  pressing  the  ENTER  key  and  the  measure 
stops  blinking. 

The  user  is  then  automatically  provided,  as  indicated  by  reverse  light¬ 
ing,  an  option  to  nau  or  label  the  object  by  calling  up  a  soft  switch  key¬ 
board  through  activation  of  the  TYPE  key.  As  noted  previously  the  "keyboard" 
may  require  at  least  partial  utilization  of  the  map  display  area.  Utiliza¬ 
tion  of  this  up  area  suit  not  occlude  the  measure  being  labelled.  After 
typing  in  the  label  for  the  uasure  the  user  again  activates  the  ENTER  key 
and  the  label  is  positioned  on  the  up  display  adjacent  to  the  uasure  in 
accordance  with  the  field  specifications  of  FM  101-5-1.  The  DELETE  key  al¬ 
lows  the  user  to  erase  or  remove  any  unwanted  measures  along  with  their  re¬ 
spective  labels  from  the  map  display. 

Additional  measures  which  are  included  in  the  user's  primary  set  are 
available  to  the  user.  They  may  be  added  by  repeating  the  same  sequence  of 
steps  as  above  as  Indicated  by  the  final  prompt.  Alternate  subsets  of  con¬ 
trol  measure  symbology,  preselected  by  the  user,  can  be  accessed  by  pressing 
the  MORE  key.  These  subsets  will  displace  the  primary  set  in  the  variable 
menu  area  in  the  order  they  were  constructed  by  the  user.  The  procedures  for 
Inputting  these  measures  onto  the  map  display  are  the  same  as  those  for  the 
primary  set. 

Each  of  the  additional  types  of  control  measures  specified  in  FM  101-5-1 
must  be  supported  by  similar  submenus  and  procedures.  Although  these  are  cot 
further  detailed  in  this  document,  the  submenu  for  the  Objectives,  Areas, 


23 


LINES,  POINTS,  BOUNDARIES 
•SELECT  MEASURE,  THEN  "ENTER"* 


LINES, 

POINTS, 

BOUNDARY 


PL -  PL  - - -  PLT 

LO -  LC  - 1 -  CO 

SP -  RP  - 1 — | -  BN 

TOUCH  TWO  MAP  POINTS,  THEN  "ENTER" 
TOUCH  TYPE"  TO  LABEL  MEASURE* 
•REPEAT  ABOVE  FOR  OTHER  MEASURES* 


TYPE 


DELETE 


ENTER 


Figure  10.  Lines,  points. 
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Figure  11.  Objectives,  areas,  positions. 
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and  Positions  (see  Figure  11)  provides  a  sample  of  the  various  control  meas¬ 
ures  and  supporting  procedures  required  for  the  remaining  types  cf  control 
measures. 


Overlays 


This  menu  provides  the  user  a  list  of  the  major  types  of  tactical  over¬ 
lays  (see  Figure  12)  to  be  reviewed,  created,  or  revised.  As  suggested  by 
the  first  prompt  the  user  may  select,  by  pressing  the  overlay  type(s)  needed, 
any  combination  of  overlays  to  review  or  inspect.  Selections  are  verified  by 
reverse  video  and  after  pressing  the  ENTER  ke>,  the  most  recently  stored 
overlay(s)  will  be  superimposed  over  the  map  display. 

If  the  user  has  selected  an  overlay  that  does  not  at  least  partially 
overlap  the  map  region  currently  depicted,  the  system  will  provide  the  user 
an  indication  of  this  incongruity  on  a  new  menu  screen  that  is  automatically 
accessed  and  returns  a  list  of  options  to  the  user  (see  Figure  13):  (1)  the 
map  area  may  be  adjusted  to  coincide  with  the  overlays(s)  requested;  (2)  the 
user  may  turn  the  map  off  temporally  and  the  overlay(s)  selected  will  be 
displayed  in  the  map  display  area;  (3)  the  user  can  request  a  list  and  the 
Iocs t loo  of  all  stored  overlays  of  the  type  requested;  or  (4)  the  user  can 
return  to  the  previous  menu  and  the  request  to  review  the  overlays  will  be 
terminated. 

If  the  overlay(s)  selected  corresponds  to  the  user's  map  area  currently 
displayed,  the  system  assumes  the  user  may  need  to  update  the  overlay(s)  and 
automatically  presents  the  Measures  Functions  (see  Figure  9)  in  the  variable 
menu  area.  The  user  then  designates  the  type  of  control  measure  to  be  added 
or  deleted  to  the  overlay  by  using  the  sane  series  of  inputs  previously  de¬ 
scribed  for  the  Measures  Functions.  When  the  user  has  completed  the  updates 
to  the  overlay  he  can  directly  store  the  updates  by  pressing  the  ENTER  key, 
or  rename  the  overlay  by  pressing  the  TYPE  key. 

As  for  the  Draw  Function,  the  user  is  then  automatically  provided,  as 
indicated  by  reverse  lighting,  an  option  to  name  or  label  the  overlay  by 
calling  up  a  soft  switch  keyboard  through  activation  of  the  TYPE  key.  This 
"keyboard-  may  require  at  least  partial  utilization  of  the  map  display  area. 
Utilization  of  this  map  area  must  not  occlude  the  overlay  being  labelled. 
After  typing  in  the  label  for  the  object  the  user  again  activates  the  ENTER 
key  and  the  label  is  positioned  on  the  map  display  adjacent  to  the  overlay  in 
accordance  with  the  field  specifications  of  FM  101-5-1.  The  DELETE  key  al¬ 
lows  the  user  to  erase  or  remove  any  unwanted  overlays  along  with  their  re¬ 
spective  labels  from  the  map  display. 

If  the  user  pressed  the  MAKE  overlay  key,  rather  than  the  REVIEW/UPDATE 
key,  the  system  assumes  the  user's  map  corresponds  to  the  area  of  interest 
and  tbe  system  proceeds  Immediately  to  the  presentation  of  listing  the  Meas¬ 
ures  Functions  (see  Figure  9)  in  the  variable  menu  area.  Again  the  user  then 
designates  the  type  of  control  measure  to  be  added  to  the  overlay  by  using 
the  sane  series  of  inputs  previously  described  for  the  Measures  Function,  and 
the  next  submenu  immediately  accesses  the  set  of  control  measures  of  overlay 
requested  by  the  user.  When  the  user  has  completed  construction  of  the  over- 
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Figure  12.  Overlays. 
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Figure  13.  Review/update. 
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lay  be  can  naae  the  overlay  by  pressing  the  TYPE  key  to  access  the  keyboard 
and  then  directly  store  this  new  overlay  by  pressing  the  ENTER  key. 


Relief 

This  submenu  provides  the  user  the  capability  to  view  a  cross-section  of 
the  terrain  (see  Fignre  14).  By  touching  any  two  points  on  the  map,  the 
terrain  relief  between  these  points  is  presented  on  the  map  display.  This 
presentation  must  not  occlude  the  terrain  region  being  viewed  in  relief.  The 
user's  designated  points  on  the  map  must  remain  verifiable  to  the  user  while 
completing  the  immediate  task,  which  in  this  case  is  comparing  this 
cross-section  with  the  area  designated.  The  cross-section  display  must  also 
provide  frame-of-reference  cues  (e.g.,  quantification  of  the  discrepancies  in 
elevation  being  inspected). 


Scroll 


This  menu  allows  the  user  to  extend  his  view  of  the  terrain  beyond  the 
immediate  area  being  displayed  on  the  system.  As  directed  by  the  prompt  the 
user  touches  the  map  area  he  would  like  to  see  and  this  location  is  scrolled 
to  the  center  of  the  screen.  The  rate  of  scroll  must  be  slow  enough  to  allow 
the  user  to  maintain  his  frame  of  reference  and  relative  location.  The  own 
vehicle  icon  maintains  its  current  location  which  is  no  longer  centered  on 
the  display  and  begins  blinking  to  better  ensure  the  user  can  readily  detect 
his  own  vehicle  location.  The  scroll  can  be  repeated  by  again  selecting  a 
new  location  to  be  moved  to  the  center  of  the  map  display.  If  the  scroll 
results  In  the  displacement  of  the  vehicle  from  the  display,  a  blinking  arrow 
will  be  presented  at  the  edge  of  the  map  that  corresponds  to  own  vehicle 
heading  and  own  vehicle  distance  (displacement  in  kilometers)  from  the  center 
of  the  nap  will  be  presented  adjacent  to  the  beading  arrow. 

It  is  noted  that  this  manual  scroll  function  is  different  than  the  auto¬ 
matic  scroll  of  the  map  that  occurs  during  own  vehicle  movement.  For  this 
automatic  scroll  the  own  vehicle  icon  remains  in  the  center  of  the  map  dis¬ 
play  and  the  map  appears  to  move  under  the  vehicle.  In  addition,  the  system 
provides  the  user  a  Zoom  Function  described  below  that  allows  him  to  change 
the  scale  r>£  the  map  (1:125,00;  1:50, 000;1:25, 000)  to  quickly  review  a  larger 
area  of  the  terrain  by  moving  to  a  scale  smaller  than  the  scale  currently 
employed.  Unique  to  the  manual  scroll,  however,  is  the  user's  ability  to 
view  In  greater  detail  (i.e.,  1:50,000;  1:25,000)  any  region  of  the  terrain 
included  in  the  system's  terrain  data  base. 


Units 

This  function  provides  the  user  access  to  predrawn  graphic  symbology  for 
depicting  on  his  map  display  both  friendly  and  threat  units  and  instal¬ 
lations.  Assuming  multicolor  capabilities,  blue  or  black  will  be  used  for 
all  friendly  units,  posts,  installations,  and  equipment  and  red  for  corre- 
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Figure  14.  Terrain  relief. 


SCROLL 


PAN/SCROLL 

TOUCH  LOCATION  ON  MAP 
YOU  WANT  AT  CENTER 
OF  THE  DISPLAY,  ENTER* 


•REPEAT  TO  SCROLL  MORE* 

NOTE:  OWN  VEHICLE 
DISPLAYED  BY  BLINKING 
ICON,  OR  HEADING  ARROW 


ENTER 


Figure  15.  Scroll. 


sponding  threat  elements.  For  a  monochromatic  display  the  friendly  symbols 
are  outlined  by  a  single  line  and  the  threat,  elements  by  double  lines  (FM 

101-5-1). 

Again,  design  for  this  function  was  based  on  the  trade-offs  between  the 
relatively  limited  area  available  on  the  BMS  display  for  report  and  message 
menus  and  the  need  for  simple,  rapid  access  to  graphic  functions  that  are 
critical  to  these  military  communications.  Similar  to  the  design  of  the 
Measures  Function,  therefore,  the  Unit  Function  provides  the  user  access  to 
the  entire  friendly  and  threat  symbology  included  in  FM  101-5-1,  but  requires 
the  user  to  preselect  a  subset  of  these  symbols  for  more  immediate  display 
requirements. 

This  pre-selection  process  allows  the  user  to  precisely  specify  the  unit 
symbology  he  wants  immediately  displayed  (e.g.,  known  enemy  threats  in  the 
area)  in  the  variable  menu  field  of  his  BMS  display.  Access  to  the  FM 
101-5-1  dictionary  of  symbols  and  the  preselection  process  is  initiated  by 
pressing  the  INITIALIZATION  key  displayed  in  Figure  16.  While  complete 
specification  of  the  initialization  process  and  supporting  menu  structures 
are  beyond  the  current  scope,  it  is  noted  that  this  initialization  is  ex¬ 
pected  to  occur  prior  to  actual  combat  operations  as  part  of  the  commander's 
weapon  station  preparation.  Given  this  preoperational  status,  the  map  dis¬ 
play  region  will  be  temporarily  transformed  to  an  extended  dictionary  display 
region  to  allow  the  user  to  readily  search  and  select  from  the  dictionary's 
contents. 

As  with  all  user  inputs,  range  control  fields  will  automatically  notify 
the  user  of  input  values  that  exceed  any  anticipated  boundaries.  For  this 
preselection  process  for  example,  the  system  will  notify  the  user  when  the 
number  of  unit  or  measures  selected  (e.g.,  6-10  symbols)  exceeds  the  immedi¬ 
ate  menu  area  available  to  the  system.  The  user  will  then  have  the  option  of 
adding  or  deleting  any  units  to  this  primary  subset,  followed  by  the  option 
to  select  a  secondary,  or  alternate,  (e.g.,  likely  enemy  threat)  subset  of 
unit  symbology,  and  any  additional  subsets  desired. 

In  addition,  it  is  also  recommended  that  the  dictionary  include  associ¬ 
ated  weapon  system  signatures,  profiles,  and  characteristics  which  might 
prove  particularly  useful  for  less  experienced  users  in  cases  of  attrition 
and  rapid  mobilization. 

Once  the  initialization  has  been  completed,  the  primary  set  of  unit  sym¬ 
bols  selected  by  the  user  is  presented  in  the  variable  menu  area  as  depicted 
in  Figure  16.  The  user  can  then,  as  indicated  by  prompts,  enter  these  unit 
symbols  on  his  map  display  by  first  pressing  the  symbol  needed  (verified  by 
reverse  video)  and  then  touching  the  map  at  the  symbol  location  (reflected  by 
the  symbol  coordinates  displayed  in  the  Point  Location  window).  The  symbol 
will  blink  until  the  user  IS  satisfied  with  the  unit/element  location  which 
is  indicated  by  touching  the  ENTER  key. 

As  indicated  by  the  next  prompt,  the  user  can  change  the  orientation  of 
the  unit,  the  system's  default  orientation  Is  North,  by  retouching  the  map  in 
direction  desired  and  the  system  verifies  this  request  by  immediately 
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Figure  17.  Zoom. 
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realigning  the  unit  in  the  direction  indicated.  If  the  user  is  not  satisfied 
with  the  orientation,  retouching  the  map  will  repeatedly  change  the  orienta¬ 
tion.  When  satisfied  with  unit's  orientation,  the  user  inputs  the  unit's 
orientation  by  pressing  the  ENTER  key. 

The  user  is  then  automatically  provided,  as  indicated  by  reverse  light¬ 
ing,  an  option  to  name  or  label  the  unit  by  calling  up  a  soft  switch  keyboard 
through  activation  of  the  TYPE  key.  This  "keyboard"  may  require  at  least 
partial  utilization  of  the  map  display  area.  Utilization  of  this  map  area 
must  not  occlude  the  unit  being  labelled.  After  typing  in  the  label  for  the 
unit  the  user  again  activates  the  ENTER  key  and  the  label  is  positioned  on 
the  map  display  adjacent  to  the  unit  in  accordance  with  the  fields  specifica¬ 
tions  of  FM  101-5-1.  The  DELETE  key  allows  the  user  to  erase  or  remove  any 
unwanted  units  along  with  their  respective  label  from  the  map  display. 

Additional  units  appearing  in  the  primary  set  available  to  the  user  may 
be  added  by  repeating  the  same  sequence  of  steps  as  indicated  by  the  final 
prompt.  Alternate  subsets  of  unit  symbology,  preselected  by  the  user,  can  be 
accessed  by  pressing  the  MORE  key.  These  subsets  will  displace  the  primary 
set  in  the  variable  menu  area  in  the  order  they  were  constructed  by  the  user. 
The  procedures  for  inputting  these  units  onto  the  map  display  are  the  same  as 
those  for  the  primary  set. 

Once  the  user  has  added  or  deleted  units  from  the  digital  map,  the  appro¬ 
priate  operational  (black)  and  enemy  (red)  overlays  must  be  updated. 


Zoom 


This  menu  provides  the  user  access  to  a  list  of  three  discrete  map 
scales:  1:25,000;  1:50,000;  and,  1:125,000  (See  Figure  17).  The  current  ma 
scale  is  indicated  by  reverse  video  and  the  user  requests  either  of  the  othe 
two  scales  by  selecting  that  option.  The  display  size  of  vehicle  icons  as 
well  as  unit  and  control  measure  symbology  must  vary  with  the  scale  of  the 
map. 


In  addition,  the  detail  of  the  topographic  data  appearing  in  the  map 
display  must  correspond  to  the  increased  detail  associated  with  military  maps 
at  the  larger  scale  sizes:  1:25,000;  1:50,000.  The  military  requirements 
for  larger  scale  topographic  displays  provide  the  user  a  more  detailed  and 
precise  representation  of  the  surface  area  including  both  man-made  and  natu¬ 
ral  terrain  features  (e.g.,  contour  lines  at  10-,  20-,  or  50-meter 
intervals) .  Mere  enlargement  of  the  same  terrain  and  man-made  features  ap¬ 
pearing  in  smaller  scale  is  not  sufficient  to  meet  the  requirements  of  small 
unit  commanders.  Conversely,  the  over-representation  of  the  same  terrain  and 
man-made  features  at  small  scales,  that  appear  in  large  scale  cartography 
will  inevitably  result  in  highly  cluttered  displays  on  the  relatively  limited 
display  surface  available  to  the  BMS. 
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CU  l  J 


COMMUNICATION  GUIDELINES 


This  section  describes  a  set  of  BMS  functional  specifications  for  commu¬ 
nicating  the  messages — reports,  orders,  and  alerts — required  for  small  unit 
command  and  control.  The  section  attempts  to  provide  designers  an  awareness 
of  the  protocols  and  formats  for  conventional  C3,  and  the  design  challenge  to 
reformat  these  procedures  in  a  manner  that  optimizes  an  automated  C3  system. 
General  design  guidelines  for  meeting  this  challenge  of  converting  from  con¬ 
ventional  to  automated  procedures  are  first  specified.  Next  the  section 
applies  these  general  guidelines  to  selected  examples  of  small  unit  communi¬ 
cations:  dedicated  reports,  status  reports  and  the  SPOT  report.  The  section 
also  includes  selected  references  that  more  thoroughly  detail  the  various 
types  of  reports  and  communications  required  for  BMS. 


The  section  will  not  attempt  to  provide  specifications  for  every  type  of 
military  communication  such  as  orders,  reports,  and  alerts  nor  for  every 
category  of  communication  within  each  type  (i.e.,  personnel,  status,  intelli¬ 
gence,  and  operations  reports).  Designers  and  users  will  need  to  iteratively 
develop  and  evaluate  alternative  formats  and  mixes  of  graphic  and  textual 
data  that  maximize  the  informational  requirements  for  C3  and  at  the  same  time 
minimize  the  senders'  and  receivers'  communication  requirements. 


Simulation  Guidelines 


The  general  design  principles  for  man-machine  interfaces — consistency, 
brevity,  flexibility,  immediate  feedback,  and  reduced  operator  workload — must 
likewise  direct  the  designer's  development  of  automated  C3  procedures  and 
formats.  The  designer  must  be  continuously  aware  of  the  multiple  processes 
and  stages  that  comprise  communication:  composing,  editing,  transmitting, 
receiving,  and  comprehending  the  message  (Hovland,  Janis,  &  Kelley,  1953; 
Lasswell  &  Casey,  1946).  The  utilization  of  automated  C3  rather  than 
voice-based  modalities  raises  numerous  trade-off  Issues  with  respect  to  each 
of  these  stages. 


O 

Automated  C  systems,  for  example,  may  effectively  separate  the  composi¬ 
tion  phase  of  communication  from  the  transmission  phase.  With  BMS,  users 
routinely  select  all  the  informational  elements  required  for  a  communication 
such  as  graphic  and  text  data  before  any  transmission  is  initiated.  After 
"drafting”  this  message  the  user  then  initiates  transmission  by  activating 
the  SEND  key.  The  message  is  then  digitally  burst  in  milliseconds  to  the 
intended  receiver,  providing  the  user  an  extremely  rapid  and  secure  medium 
for  transmitting  messages. 


Voice-based  devices,  on  the  other  hand,  such  as  the  EM  radio  require 
relatively  extended  transmission  times  that  not  only  compromise  security  but 
provide  no  formal  record  of  the  messages'  contents.  Users  receiving  any 
message  are  generally  forced  to  take  immediate  notes  particularly  of  the 
spatial-geographic  data  such  as  the  grid  coordinate  locations  of  units,  meas¬ 
ures,  and  target  reference  points.  These  notes  are  generally  made  in  the 
same  alphanumeric  format  they  are  received  (e.g.,  six-  or  eight-digit  grid 
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numbers)  and  then  later  recoded  or  spatially  plotted  onto  the  users'  paper 
maps  or  acetate  sheets.  If  the  message  must  be  forwarded  to  another  user,  as 
is  often  the  case,  the  processes  must  be  repeated  since  no  FM  record  exists. 


Vehicle  based  automated  C3  systems  are  not  expected  to  provide  reliable 
speech  synthesis  and  recognition  capabilities  in  the  forseeable  future.  To 
provide  digital  communications  and  records,  therefore,  BMS  will  require  users 
to  communicate  alphanumeric  data  by  either  selecting  preformatted  items  from 
a  menu  of  response  options  (e.g.,  tank,  truck,  fixed  wing,  etc.,)  or 
formatting  their  own  responses  via  an  alphanumeric  keyboard,  "a  typewriter  in 
the  tank."  Voice-based  systems,  on  the  other  hand,  require  no  visual  search 
and  manual  selection  among  the  available  response  options  listed  on  a 
menu-based  system  such  as  BMS.  The  communication  of  selected  alphanumeric 
data  items  may,  therefore,  prove  more  demanding  in  an  automated  Cr  system 
than  in  a  voice-based  system  such  as  conventional  FM. 


The  designers'  awareness  of  these  trade-offs  between  conventional 
and  automated  C3,  should  continually  guide  their  design  and  developmental 
efforts  for  each  phase  of  the  communication  process.  The  general  communica¬ 
tion  guidelines  presented  below  and  the  specific  applications  of  these  guide¬ 
lines  presented  in  a  following  section  attempt  to  maximize  these  trade-offs. 


Maximize  Graphic  Capabilities 

•3 

The  primary  intent  of  an  automated  C  system  is  to  provide  users  a  medium 
that  more  rapidly,  easily,  and  accurately  transmits  battlefield  information 
critical  to  both  the  planning  and  execution  of  military  operations,  particu¬ 
larly  in  a  combined  arms  effort.  The  earlier  discussion  of  BMS  map  functions 
stressed  that  spatial-geographic  data  is  central  to  C3  and  that  military 
communications  via  map-base  spatial  analogs  provide  a  more  Intuitive,  rapid, 
and  accurate  mode  for  this  information  than  voice-based  modalities  which  are 
characterized  by  alphanumeric  data.  Alphanumeric  data,  however,  are  still 
required  to  supplement  map-based  Information  and  provide  the  detailed  data 
necessary  to  fully  Interpret  tactical  intentions  and  precisely  identify  and 
categorize  informational  elements  such  as  unit  and  control  measure  symbology. 

The  dichotomy  between  spatial-geographic  data  and  alphanumeric  data  is 
emphasized  to  provide  the  designer  a  better  understanding  of  the  users'  dis¬ 
parate  needs  and  requirements  particularly  with  respect  to  conventional  C 3 
procedures.  The  dichotomy,  however,  is  somewhat  arbitrary  in  that  mos'  spa¬ 
tial-geographic  data,  for  example,  can  be  transduced  or  encoded  into  alphanu¬ 
meric  elements.  Unfortunately,  conventional  voice-based  C3  procedures  have 
forced  soldiers  to  repeatedly  encode  spatial-geographic  data'  into  alphanu¬ 
meric  elements  at  the  sender's  station  and  then  required  other  soldiers  to 
decode  the  same  elements  back  to  spatial-geographic  data  at  the  receiver's 
station.  An  extremely  simple  and  critical  battlefield  communication  such  as 
a  SPOT  report  of  enemy  contact,  for  example,  becomes:  "Five  T-72  tanks  trav¬ 
eling  North  grid  Echo  Sierra  two,  four  six,  seven,  two,  one  at  one,  five, 
five,  two,  Zulu." 
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Most  military  communications,  and  particularly  tactical  communications, 
must  convey  spatial-geographic  information  about  the  geometry  of  the  battle¬ 
field  and  rarely  is  that  information  limited  to  a  single  coordinate  location 
as  in  the  above  SPOT  report.  More  complex  battlefield  communications  which 
are  voice  based,  therefore,  require  the  repeated  encoding  and  decoding  of 
multiple  locations,  and  even  more  demanding,  the  boundaries  of  circumscribed 
areas  such  as  battle  positions,  assembly  areas,  contamination  areas,  and  ob¬ 
stacles.  The  voice-based  communication  of  this  information  is  intensely 
time-consuming,  demanding,  and  error-prone.  Graphic  communications  of  spa¬ 
tial-geographic  information,  on  the  other  hand,  are  structurally  isomorphic 
to  the  combat  units,  events,  and  processes  they  represent  and  require  no 
transfer  or  recoding  into  alphanumeric  formats.  To  input  the  location  of  the 
T72  tanks  for  the  above  SPOT  report,  for  example,  the  user  simply  indicates 
their  position  by  touching  his  map  display  at  the  corresponding  location. 

If  BMS  is  to  effectively  automate  and  facilitate  the  command  and  control 
process  the  communication  modality  must  capitalize  on  the  unique  capabilities 
of  digital  graphic  communications.  Designers  must  continuously  and  itera¬ 
tively  work  with  the  users  to  exploit  this  unique  capability  and  both  groups 
must  realize  that  it  represents  a  significant  departure  from  conventional  CJ 
procedures.  This  is  particularly  true  for  the  bottom-up  communications  such 
as  reports  from  tank  commanders  and  platoon  leaders  since  conventional  doc¬ 
trinal  formats  and  standard  operating  procedures  (SOP)  are  designed  for 
voice-based  reports  (FM). 


User-Tailored  Options 

An  overriding  guideline  for  BMS  design  architecture  is  the  provision  of 
user-specific  options.  As  the  battalion-down  automated  command  and  control 
system,  BMS  must  be  designed  to  adapt  to  the  needs  of  multiple  users  with 
differing  tasks,  areas  of  interest,  and  even  missions.  To  expedite  the  CJ 
process,  and  at  the  same  time  establish  a  uniform  software  and  data  base 
architecture  for  all  small  unit  BMS  applications,  the  design  of  the  BMS  func¬ 
tional  capabilities  must  allow  users  the  opportunity  to  customize  display  and 
control  options  in  a  manner  that  best  supports  their  current  duty  and  mission 
requirements. 

The  development  of  the  FM  101-5-1  library  of  unit  and  control  measure 
symbology  previously  discussed  (see  Map  Functions),  for  example,  included 
initialization  stages  in  which  each  user  first  accesses  the  complete  diction¬ 
ary  and  then  selects  subsets  of  the  various  unit  and  control  measure  antici¬ 
pated  for  his  communication  requirements.  The  ability  to  tailor  the  displays 
and  controls  to  each  user's  requirements  supports  the  need  for  rapid  access 
and  execution  of  the  BMS  command  and  control  functions  and  at  the  same  time 
the  library  provides  a  common  data  base  for  computer  files,  processing,  and 
records  of  small  unit  communications.  Similarly  the  user's  ability  to  selec¬ 
tively  call-up  and  delete  natural  and  man-made  terrain  features  as  well  as 
tactical  overlays  Is  intended  to  provide  multi-level  users  a  powerful  yet 
uniform  interface  for  planning,  communicating,  and  executing  battlefield 
operations. 
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In  addition,  as  noted  in  the  earlier  discussion,  the  BUS  display  areas 
and  response  options  are  restricted  by  the  relatively  limited  size  (e.g., 
9-inch  diagonal)  projected  for  the  user  interface  in  a  combat  vehicle.  The 
capability  for  each  user  to  tailor  his  display  and  control  functions  for 
maximal  utilization  of  this  interface  space  is  a  high  design  priority. 


Automated  Communications 


The  highest  design  priority  for  BMS  is  to  completely  automate  as  much  of 
the  procedures  as  possible.  For  some  informational  elements — such  as 
routine  status  reports  of  fuel,  ammo,  and  weapon  system  status  and 
location — communications  should  be  completed  without  any  Intervention  by  the 
user.  For  other  types  of  information  such  as  intelligence  updates  of  enemy 
contact  detected  by  battlefield  sensor  systems  which  are  transmitted  from 
automated  systems,  the  receivers  only  requirement  might  be  to  activate  the 
RECEIVE  key.  For  numerous  types  of  communications  which  require  the  distribu¬ 
tion  of  battlefield  information  among  different  users  and  even  echelons,  the 
re- transmission  of  this  information  should  require  little  more  than  activa¬ 
tion  of  SEND,  RECEIVE,  and  radio  net  keys. 

Ideally,  this  automated  routing  of  battlefield  communications  might  be 
accomplished  by  knowledge-based  systems  developed  to  automatically  parse  the 
message  (e.g.,  OPORDs)  into  smaller  subpackets  of  information  directly  re¬ 
lated  to  the  requirements  of  different  users  (e.g.,  combat,  combat  service, 
combat  service  support,  artillery  etc.).  Near  term  implementations  of  BMS, 
however,  are  not  expected  to  provide  this  knowledge  base,  and  human  interven¬ 
tion  will  be  required  to  ensure  that  users  receive  only  the  information 
needed.  The  goal  for  designers  nevertheless  is  to  minimize  the  procedures 
for  distributing  this  type  of  information.  Ihe  need  for  doctrinal  changes  to 
traditional  Cr  procedures  quickly  surfaces,  and  for  this  example  may  require 
that  the  conventionally-fixed  format  for  writing  and  issuing  an  OPORD  may  re¬ 
quire  modifications  that  would  more  readily  support  automated  or  partially 
automated  parsing  and  distribution  of  battlefield  data. 


Automated  Information 


One  of  the  most-critical  design  requirements  for  an  effective  automated 
system  is  to  routinely  and  automatically  include  informational  elements 
such  as  call  signs  and  authentication  procedures  which  are  required  for  every 
battlefield  communication.  While  the  majority  of  Cr  communications  will 
require  that  users  compose  their  own  messages,  unlike  the  automated  communi¬ 
cations  just  discussed,  a  primary  objective  of  the  design  must  be  to  automat¬ 
ically  Include  Informational  elements  like  sender  and  vehicle  identifiers, 
date  and  time  groups,  and  authentication  checks,  that  currently  belabor  con¬ 
ventional  communication  requirements.  Data  from  the  National  Training  Center 
(NTC) ,  for  example,  suggest  that  call  signs  and  authentication  procedures 
account  for  over  502  of  all  time  spent  on  the  communication  nets  during  com¬ 
pany  level  exercises  (Phelphs  &  Kupets,  1984).  Similarly  incoming  messages 
should  be  time-and  user-stamped  for  both  receipt  and  acknowledgement  proce¬ 
dures,  and  a  distribution  log  thus  maintained  for  battlefield  data  which 
might  be  subject  to  multiple  transmissions. 
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Automated  records  of  this  type  will  prove  invaluable  for  determining  the 
validity  (i.e.,  confidence  estimates)  of  intelligence  data,  establishing  the 
archival  logs  of  prior  communications,  developing  rules  for  purging  intelli¬ 
gence  overlays  of  outdated  information,  and  identifying  multiple  reports  of 
the  same  information  by  correlating  across  time,  location,  and  source  files. 
In  addition,  this  automated  information  will  serve  in  documenting  actual 
small  unit  communication  patterns  for  the  later  development  of  more 
automated  distribution  capabilities  and  hierarchical  command  filters  for 
restricting  informational  access  to  selected  user  subsets. 


Automated  Encryption 

Command  and  control  requirements  in  voice-based  systems  are  exacerbated 
considerably  when  the  Security  of  Communication  Activity  Level  (SCALE)  ex¬ 
ceeds  I  which  assumes  "that  all  communications  will  be  passed  in  the  clear" 
(FC  71-6,  p  1-7).  At  higher  levels  such  as  SCALE  II  and  III  the  encoding  and 
decoding  tasks  seriously  degrade  C3  efficiency  and  effectiveness.  Since  BMS 
communications  require  precom posit Ion  before  they  are  transmitted,  transmis¬ 
sion  times  are  significantly  decreased.  Vhen  this  reduction  is  coupled  with 
digital  burst  transmission  and  the  SINCGARS  (single  channel  ground  and 
airborne  radio  subsystems)  radio  interface,  BMS  should  provide  a  much  more 
secure  communication  modality  (particularly  when  automated  user  identifica¬ 
tion  routines  are  implemented).  If  encryption  is  required,  however,  the  de¬ 
sign  should  include  automated  procedures  for  encoding  and  decoding 
battlefield  Information.  By  eliminating  the  need  for  user-based  encryption, 
BMS  will  have  significantly  reduced  the  .  burden  and  Increased  both  Its 
efficiency  and  effectiveness. 


Automated/Repeated  Transmission 

Conventional  C3  procedures  require  that  users  directly  participate  in  the 
transmission  process,  they  serve  as  the  input  device  for  voice-based  communi¬ 
cations.  Data  from  the  HTC,  again  for  company  level  exercises,  demonstrate 
that  small  unit  commanders  aust  wait,  on  the  average,  28  seconds  simply  to 
gain  access  to  the  nets  to  begin  a  transmission  (Phelphs  &  Kupets,  1984). 
Because  the  user  is  also  a  transmitter  in  voice-based  systems,  the  user  must 
not  ooly  attend  to  the  communication  while  awaiting  access  to  the  net  but 
also  during  the  actual  transmission.  And  since  most  messages  are  composed 
of  multiple  transmissions  (to  reduce  transmission  time  and  maintain  security) 
and  multiple  waits  to  access  the  net  for  each  of  these  transmissions,  the 
transmission  process  requires  a  substantial  Investment  of  time  and  attention 
by  the  user. 

The  BMS  design  must  provide  the  user  a  medium  for  minimizing  the  time  and 
attention  required  for  FM  tranr mission.  By  allowing  the  user  to  compose 
communications  independently  of  their  transmission,  BMS  provides  a  "flre-and- 
forget"  quality  to  the  transmission  process.  BMS  transmissions  are  initiated 
by  the  user  touching  the  SEND  key  and  the  system  must  then  automatically 
direct,  monitor,  and  repeatedly  transmit  the  message  to  the  designated  re¬ 
ceiver  until  the  message  has  been  completely  recorded  by  the  receiving  sta¬ 
tion. 
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Because  the  message  Is  recorded  in  a  digital  format  and  stored  by  the 
sender's  system,  the  transmission  can  be  repeated  automatically  in  the  event 
that  part  or  all  of  the  transmission  is  lost  due  to  any  of  the  various  types 
of  interference  that  impede  military  communications  (e.g.,  static,  background 
noise,  garble,  distance,  terrain  obscuration,  jamming,  etc.)*  Nearly  a  third 
of  all  small  unit  transmissions  experience  interference  at  the  NTC  (Phelps  & 
Kupets,  1984).  The  digital  burst  of  BHS  (versus  the  extended  vocalization 
time  of  FM)  will  not  only  reduce  these  Interference  rates,  but  the  design 
must  ensure  that  BHS  will  automatically  rebroadcast  messages  that  are  lost  or 
partially  Interfered  with,  without  any  additional  user  tasking. 


Vehicle-Based  Functions 


The  BHS  guidelines  and  functions  previously  discussed  have  provided  de¬ 
signers  the  tools  and  specifications  for  many  of  the  supporting  functions 
needed  for  developing  the  REPORT  functions  required.  This  report  has  focused 
on  the  vehicle-based  BHS  systems  of  the  lower  echelons  within  the  battalion, 
and  in  particular  the  vehicle-based  BHS  Interface.  For  vehicle-based  sys¬ 
tems,  the  overriding  design  philosophy  for  BHS  is:  Keep  it  simple.  From 
this  perspective,  the  vehlcled-based  user  is  primarily  a  receiver,  not  the 
generator,  of  the  more  complicated  communications  such  as  the  OPORD  composed 
and  issued  from  a  battalion  tactical  operations  center  (TOC).  And  the  bat¬ 
talion  OPORD  is  a  refinement  of  a  higher  echelon  mission  that  the  TOC  has 
received.  It  is  important  that  designers,  and  sponsors,  of  lower  echelon 
automated  (~  systems  are  aware  of  this  informational  context  within  which  BMS 
operates.  It  allows  vehicle-based  commanders  to  focus  on  fighting  the  battle, 
by  providing  them  the  informational  "tools"  to  rapidly  and  easily  generate 
their  own  communications. 

In  contrast,  the  format  of  the  OPORD  is  an  intricate  and  relatively  com¬ 
plex  structure  which  can  only  be  outlined  in  a  five  paragraph  statement: 
situation,  mission,  execution,  service  support,  and  command  and  signal.  The 
order  Itself  is  composed  of  numerous  subparagraphs  of  highly  detailed  data 
and  formats,  and  is  supported  by  various  annexes  that  correspond  to  the  over¬ 
lay  types  previously  discussed  under  Hap  Functions.  The  BMS-based  terminal 
at  the  battalion  TOC  must  support  the  preparation,  refinement  and  issue  of 
this  order.  The  vehicle-based  BHS  terminals  should  be  designed  to  receive 
this  data — and  ideally,  only  those  portions  of  the  order  necessary  for  the 
user  to  understand  his  commander's  concept  of  the  operation,  and  the  user's 
role  in  support  of  this  operation. 

The  construction  of  the  operational  overlays  and  the  supporting  graphic 
and  control  measures  will  primarily  be  performed  by  nonvehicle-based  systems 
with  larger  displays,  processors  and  data  bases.  The  BHS  users  will  gener¬ 
ally  be  the  recipients  of  this  information,  but  not  the  originators.  Never¬ 
theless,  the  BHS  makes  digital  transmission  and  reception  of  this  information 
possible  and  helps  to  ensure  that  lower  echelon  users  receive  command  and  control 
data  in  a  more  timely,  uniform,  accurate,  and  secure  manner  than  is  possible 
with  conventional  command  and  control  procedures. 
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This  informational  context  will  greatly  reduct:  the  vehicle-based  users' 
requirements  to  generate  their  own  overlays  and  graphics  from  scratch.  Their 
utilization  of  BMS  for  planning  will  primarily  require  supplementation  to 
this  data  base,  the  informational  context  will  have  been  provided  by  other 
users.  Platoon  leaders,  for  example,  will  generally  only  need  to  refine  the 
graphics  provided  by  upper  echelon  users.  The  platoon  leader  in  a  defensive 
mission,  to  continue  the  example,  might  more  precisely  orient  the  graphics 
provided  for  his  battle  position  “goose  egg"  and  realign  his  sectors  of  fire. 
But  the  original  military  symbols  for  these  position  and  sector  graphics 
should  be  generated  onto  the  map  display  by  personnel  in  the  battalion  TOC 
using  their  nonvehlcle-based  systems  and  then  transmitting  these  overlays  to 
the  platoon  leaders. 

Considerable  effort  has  already  been  invested  in  the  design  of  higher 
echelon  automated  systems,  and  most  notably  the  Maneuver  Control  System 
(HCS)  with  which  the  BMS  must  Interface.  Designers  of  BMS  should  be  aware  of 
this  relationship  and  the  design  concepts  employed  in  the  MCS,,  but  the  cur¬ 
rent  task  does  not  include  the  development  of  a  BMS-MCS  interface.  It  is 
important  to  maintain  this  perspective  for  a  number  of  reasons  Including  the 
development  an  Integrated  Army  Command  and  Control  System.  The  issue  is 
primarily  raised  at  this  time,  however,  because  the  design  of  a  vehicle-based 
C^  system  Independently  capable  of  formatting  an  OPORD  on  a  smell  screen 
Interface  la  more  than  challenging — and  fortunately  not  required  for  this 
report's  focus  on  vehicle-based  BMS. 

Cp  Documentation 


Designers  mast  extend  these  guidelines  to  support  all  small  unit  command 
and  control  communications  which  arc  primarily  classified  as  orders,  alerts, 
and  reports.  Key  reference  documents  for  identifying  conventional  small  unit 
command  and  control  requirements  are:  FC  71-6,  “Battalion/Brigade  Command 
and  Control,”  and  FC  17-17,  "The  Division  86  Tank  Battalion/Task  Force  SOP, 
Coordinating  Draft."  The  71-6  document  provides  the  most  definitive  refer¬ 
ence  for  identifying  the  data  elements  and  formats  required  for  orders  in¬ 
cluding:  Operation  (OPOBDS),  Warning  Orders  and  Fragmentary  (FRAG)  Orders; 
and  alerts  such  as  Air  Defense,  Readiness  Condition  Status;  Nuclear,  Bio¬ 
logical,  and  Chemical  (NBC);  and  incoming  graphics,  messages,  and  reports. 

The  FC  17-17  document  provides  a  definitive  reference  for  the  data  elements 
aad  formats  required  for  reports  including:  Personnel  (Red),  Intelligence 
(Green),  Logistics  (Yellow),  Operations  (Blue),  as  well  as  Shell  and  NBC. 

Supporting  documentation  for  the  specification  of  small  unit  command  and 
control  requirements  is  provided  by  Standard  Operating  Procedures  (SOP)  Manu¬ 
als:  FC  17-16  "The  Division  86  Tank  Company  SOP,"  Coordinating  Draft,  and  FC 
17-15-3  "Tank  Platoon  SOP."  These  SOP  manuals  will  provide  designers  an 
excellent  summary  of  the  data  elements  and  formats  required  for  bottom-up 
comm ica t ions  within  the  battalion. 

One  additional  reference  that  designers  need  to  be  familiar  with  is 
"IVIS:  Intervehicular  Information  System"  a  draft  document  generated  by  the 
Directorate  of  Combat  Developments,  Spring  1987.  The  IVIS  document  is 
USAARMC's  specification  of  the  command  and  control  functions  required  for  a 
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base-line  automated  system  which  is  envisioned  as  the  starter-set  for  BMS. 
The  IVIS  document  provides  an  excellent  summary  and  overview  not  only  of  the 
base-line  operational  command  and  control  requirements  for  users,  but  also 
the  materials  required  for  training  aids  in  support  of  preoperations  checks 
and  planning.  In  addition,  the  document  specifies  the  requirement  for  an 
IVTS  tutorial  and  provides  designers  overviews  of  the  subsystem  integration 
of  M1A1  components  required  for  blt/bite  diagnostics  as  well  as  maximal 
utilization  of  the  automated  C3  Interface. 


Guideline  Applications 

The  following  section  demonstrates  applications  of  the  guidelines  of  the 
above  communication  functions.  The  applications  are  limited  to  selected 
reports — dedicated  reports,  status  reports,  and  the  Spot  report.  The  intent 
of  this  section  is  to  exemplify  utilization  of  the  guidelines  and  demonstrate 
the  potential  reduction  in  command  and  control  requirements  as  a  result  of 
automated  Cr  systems. 


Dedicated  Reports 

In  fast  moving  tactical  situations,  timely  reporting  of  enemy  actions  is 
critical.  The  prototype  BMS  provides  dedicated  report  keys  for  the  most 
important  of  these  reports.  Dedicated  report  keys  allow  the  user  to  gener¬ 
ally  bypass  the  menu  structure  of  the  BMS  REPORT  function  and  relay  critical 
Information  quickly.  The  dedicated  report  keys  are  exemplary  applications  of 
how  automated  Cr  systems  might  provide  user-based  real  time  updates  of  bat¬ 
tlefield  information  throughout  the  battalion,  greatly  reduce  the  users' 
requirements  for  communicating  this  information,  and  render  BMS  an  effective 
force  multiplier. 

These  are  abbreviated  report  functions  which  in  bypassing  the  more  formal 
REPORT  formats  also  bypass  some  of  the  doctrinal  and  SOP  elements  currently 
required.  Each  of  these  report  types  must,  therefore,  also  be  Included  under 
the  REPORT  functions  in  a  nonabbrevlated  manner  that  contains  the  data  ele¬ 
ments  and  formats  currently  required  by  doctrine  and  SOP.  The  dedicated 
report  keys  provide  the  user  an  alternative  format  for  expediting  these  com¬ 
munications  in  a  manner  that  quickens  the  decision  and  response  cycle.  When 
more  detailed  Information  is  required,  or  as  time  allows,  users  will  exercise 
the  option  to  submit  this  information  under  the  REPORT  functions. 

Contact,  lihen  enemy  units  are  encountered  the  user  can  rapidly  initiate 
a  report  of  enemy  contact  by  activating  the  CONTACT  key.  Pressing  the  CON¬ 
TACT  key  accesses  the  menu  appearing  in  Figure  18  which  directs  the  user  to 
first  "fix**  the  enemy  units  by  touching  the  map  at  their  location.  This  re¬ 
sults  in  a  blinking  icon  appearing  on  the  map  display  at  that  point  and  the 
coordinate  location  of  that  point  appearing  in  the  Point  Location  window  at 
tbe  bottom  of  the  map  display.  Retouching  the  map  results  in  relocation  of 
the  blinking  icon. 

The  user  is  then  prompted  to  identify  the  type  of  enemy  unit  contacted  by 
selecting  from  the  subset  of  enemy  units  previously  selected  during  the  INI- 
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TIALIZATION  phase  (see  Units  under  Hap  Functions).  It  will  be  recalled 
that  the  user  has  selected  this  subset  of  potential  enemy  units  on  the  basis 
of  his  assigned  mission  and  supporting  intelligence  data.  The  subset,  there¬ 
fore,  reflects  the  known  or  likely  enemy  units  which  might  be  encountered  in 
this  area.  Upon  selection  of  a  unit  type  the  blinking  Icon  on  the  map  dis¬ 
play  converts  to  a  blinking  symbol  corresponding  to  the  unit  selected.  If 
the  unit  type  is  not  present  in  the  initial  subset,  the  user  is  directed  to 
select  MORE  which  accesses  the  alternate  subset  of  unit  types  previously  se¬ 
lected  daring  INITIALIZATION. 

The  aser  is  then  directed  to  Indicate  the  direction  of  movement  (if  the 
unit  is  not  stationary)  by  touching  the  nap  adjacent  to  the  unit  in  the  di¬ 
rection  the  unit  appears  to  be  aovlng.  A  blinking  arrow  or  vector  symbol 
appears  on  the  nap  corresponding  to  the  direction  indicated,  and  this  direc¬ 
tion  can  be  adjusted  by  retouching  the  nap  in  another  direction.  If  the  user 
is  satisfied  with  the  accuracy  of  the  data  depicted  on  the  map,  the  user  is 
directed  to  touch  the  ENTER  key  and  blinking  of  the  icons  is  terminated.  The 
user  then  communicates  this  data  by  touching  the  SEND  key. 

Call  For  Fire.  One  of  the  most  critical  and  time-dependent  communica¬ 
tions  for  small  unit  commanders  is  the  request  for  Indirect  artillery  fire. 
Conventional  procedures  for  communicating  this  request  are  complicated  by 
(1)  extrapolation  of  enemy  location  (six-digit,  polar  plot,  shift),  (2)  for¬ 
mats  requiring  five  additional  informational  elements  (identification  of 
observer,  warning  order,  target  description,  method  of  engagement,  method  of 
fire  and  control),  and  (3)  selection  of  the  Fire  Support  net.  The  Call  For 
Fire  dedicated  report  function  drastically  reduces  these  requirements  by 
providing  the  users  an  alternative  function  for  rapidly  requesting  artillery 
fires.  Again  users  must  be  provided  a  more  doctrlnally  complete  format  for 
Call  For  Fire  under  the  REPORT  function. 

By  pressing  the  CALL  FOR  FIRE  key  users  access  the  menu  appearing  In 
Figure  19  which  directs  them  to  "fix'*  the  enemy  units  by  touching  the  map  at 
tbelr  location.  Again  the  subset  of  unit  types  appears  in  the  variable  menu 
area  and  the  second  prompt  allows  users  to  describe  the  enemy  in  a  manner 
Identical  to  that  under  CONTACT.  Subfunctlons  such  as  relocation  of  enemy 
units,  access  to  alternate  subsets  of  units,  and  data  entry  are  also  Identi¬ 
cal  to  that  under  CONTACT;  but  these  elements  may  again  be  omitted  at  user's 
discretion.  Activation  of  the  CALL  FOR  FIRE  key  also  switches  the  net  to  the 
Fire  Support  Officer  (FIST)  automatically.  At  a  minimum  the  U6er  can  request 
indirect  fires  by  touching  the  (1)  CALL  FOR  FIRE  key,  (2)  the  map  at  enemy 
location,  and  (3)  the  SEND  key. 

NBC.  Activation  of  the  NBC  key  sounds  an  alarm  that  alerts  the  unit  to 
mask  In  protective  gear.  Once  the  user  touches  the  ENTER  and  SEND  key,  a 
similar  alert  is  sent  to  neighboring  units.  In  addition,  activation  of  this 
key  accesses  the  menu  appearing  In  Figure  20  which  directs  the  user  to  first 
specify  the  type  of  agent,  and  then  the  location  of  the  contamination  upon 
the  map  display.  A  blinking  military  symbol  for  that  agent  appears  on  the 
map  display  and  If  the  user  is  satisfied  with  the  accuracy  of  the  data, 
blinking  Is  terminated  and  data  entered  by  touching  the  ENTER  key.  Activa¬ 
tion  of  the  SEND  key  completes  thiif  abbreviated  NBC  report  which  again  must 
have  a  more  doctrlnally  complete  format  under  the  REPORT  function. 
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Figure  18.  Contact  report. 


Figure  19.  Call  for  fire  report. 
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States  Reports 


The  States  function  provides  the  current  operational  status  of  the  user's 
unit  personnel,  vehicle,  and  equipaent.  All  status  Information  is  to  be 
initially  presented  to  users  in  color-coded  formats  (i.e.,  black,  amber, 
green,  or  blue)  which  correspond  to  the  relative  operational  status  of  se¬ 
lected  components.  Designers  are  referred  to  71-6  "Battalion/Brigade  Command 
and  Control,"  1  March  1985,  for  specifications  of  these  color-coded  formats. 
In  addition  states  information  should  be  maintained  in  alphanumeric  formats 
which  pcvvlde  more  precise  data  about  component  status  for  issues  of  resupply 
and  Combat  Service  Support. 

Figure  21  presents  a  main  menu  listing  some  of  the  required  status  sub¬ 
menus  (e.g.,  personnel,  vehicle,  and  equipaent).  For  example,  the  submenu  of 
Equipment  Status,  Figure  22,  presents  a  list  of  vehicle  components  which  are 
color  coded  to  reflect  current  operational  status.  Pressing  one  of  the  menu 
selections  gives  the  same  information  for  the  subsystems  of  the  tank.  For 
example.  Figures  24  through  25  are  supporting  submenus  to  Figure  22,  that 
provide  status  information  for  selected  vehicle  components.  Figure  26  pro¬ 
vides  personnel  status  data  that  must  be  updated  by  the  user.  The  TYPE  func¬ 
tion  allows  the  user  to  edit  the  reported  status.  Summary  data  from  all 
tanks  are  sent  to  the  platoon  sergeant's  tank  and  form  one  of  the  automatic 
components  of  the  FITREP. 


Reports  and  Orders 

Activation  of  the  REPORTS  function  accesses  a  main  menu  as  depicted  in 
Figure  27  which  provides  the  user  a  list  of  the  primary  categories  for  commu¬ 
nicating  and  reviewing  command  and  control  data:  Orders,  Alerts  and  Reports. 
Application  of  the  communication  guidelines  will  be  presented  for  the  SPOT 
report. 

Spot  Report.  The  users  activation  of  the  REPORTS  key  accesses  the  menu 
shown  in  Figure  27  which  provides  a  list  of  the  major  typec  of  Cr  communica¬ 
tions.  By  selecting  Reports  from  this  list  and  then  ENTER,  as  indicated  by 
the  prompts,  the  user  accesses  a  menu  of  report  types  as  depicted  in  Figure 
28.  The  report  options  Included  In  this  list  are  based  on  either  user-level 
default  items  automatically  provided  by  the  BMS,  or  they  are  the  report  types 
selected  by  the  user  as  his  primary  set  of  reports  during  an  INTIATIALIZATION 
procedure  Identical  to  that  described  for  Unlt£;  and  Measures.  The  library  of 
report  types  and  required  data  formats  and  elements  are  specified  by  the 
three  user-specific  SOP  Manuals  previously  cited.  From  the  menu  of  report 
types  the  user  selects,  for  this  application,  the  SPOT  report.  The  SPOT 
reports  Is  used  when  known  or  likely  enemy  units  have  been  observed. 

After  entering  his  selection  of  the  SPOT  report,  the  user  is  provided  the 
menu  appearing  in  Figure  29  which  lists  various  types  of  enemy  units  and  a 
numeric  keypad  for  indicating  the  type  and  strength  of  units  observed.  The 
units  depicted  in  this  menu  are  the  same  as  those  selected  by  the  user  as  his 
primary  subset  of  known  or  likely  enemy  units  during  INITIALIZATION.  Again, 
by  activating  the  MORE  key,  alternate  subsets  selected  by  the  user  may  be 
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Figure  21.  Status  menu. 
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Figure  22.  Vehicle  status. 
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Figure  23.  Engine  components. 
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Figure  24.  Drivetrain  status. 
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Figure  26.  Personnel  status. 
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REPORT  TYPES 

‘SELECT  ONE,  THEN  "ENTER"* 

REPORTS 

N 

SPOT 

SHELL 

NEW 

/ 

S1TREP 

CALL  FOR  FIRE 

NBC-1 

NBC-3 

INITIALIZE 
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Figure  28.  Report  types. 
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accessed.  After  selecting  the  type  of  enemy  unit  observed,  reflected  by 
reverse  video,  the  user  is  prompted  to  specify  the  number  of  units  detected 
via  the  numeric  keypad.  Users  inputs  via  the  keypad  are  echoed  'ck  in  the 
data  field  window  and  the  user  can  edit  his  entry  with  the  CLEAL  and  DELETE 
keys.  When  the  user  is  satisfied  with  the  accuracy  of  his  data,  activation 
of  the  ENTER  key  automatically  accesses  the  Activity  and  Location  menu  de¬ 
picted  in  Figure  30. 

The  Activity  and  Location  menu  provides  a  format  for  specifying  enemy  and 
own  activity  as  well  as  enemy  location.  As  indicated  by  the  prompts,  the 
user  first  selects  the  appropriate  activity  levels  for  enemy  and  then  own 
units,  and  then  is  directed  to  indicate  enemy  location  by  touching  the  map 
display.  This  location  is  reflected  back  to  the  user  by  a  blinking  icon  and 
the  entry  of  enemy  coordinate  data  in  the  Point  Location  window.  When  satis¬ 
fied  with  the  data,  the  user  touches  ENTER. 

If  the  user  indicated  that  enemy  units  were  "Moving"  under  the  Activity 
and  Location  menu,  selection  of  the  ENTER  key  automatically  accesses  the  menu 
in  Figure  31  requesting  the  direction  and  speed  of  enemy  movement.  The 
prompts  for  this  menu  direct  the  user  to  indicate  direction  by  touching  the 
map  display  adjacent  to  the  enemy  unit  symbol  previously  entered  (with  orien¬ 
tation  adjustments  the  same  as  discussed  before  under  Units  and  Measures), 
and  then  to  use  the  keypad  for  indicating  estimated  speed  of  movement.  If 
the  user  selected  "Observing"  or  "Engaging”  under  the  Activity  and  Location 
menu,  however,  the  ENTER  key  activation  of  that  menu  bypasses  the  Direction 
and  Speed  menu  (Figure  31)  and  automatically  access  the  Summary  menu  appear¬ 
ing  In  Figure  32. 

The  Summary  menu  provides  the  user  the  opportunity  to  review  and  edit  the 
SPOT  report  before  transmission.  If  satisfied  with  the  SPOT  report  data  the 
user  touches  the  SEND  key  to  transmit  the  message.  If  the  user  wishes  to 
edit  the  information  in  any  of  the  data  fields  the  user  selects  that  field, 
as  indicated  by  the  prompt,  and  the  system  accesses  the  supporting  menu 
(28-31)  from  which  this  data  was  obtained.  After  editing  the  supporting  menu 
and  touching  ENTER  the  user  is  returned  to  the  Summary  menu.  When  editing  is 
completed  the  user  touches  the  SEND  key  to  transmit  the  SPOT  report. 


POSNAV  GUIDELINES 

The  POSNAV  system  is  an  Integral  component  for  supporting  many  of  the  BMS 
automated  functions.  POSNAV' s  ability  to  monitor  own-vehicle  location  and 
heading  completely  automates  some  of  the  most  critical  and  demanding  require¬ 
ments  for  small  unit  maneuver  forces. 

When  POSNAV  capabilities  are  integrated  with  other  vehicle  subsystems 
cumulative  effects  are  realized,  particularly  with  respect  to  the  communica¬ 
tion  of  battlefield  information.  POSNAV  linked  with  the  laser  range  finder 
(LRF)  data,  for  example,  provides  the  capability  for  automatically  determin¬ 
ing  and  communicating  the  location  of  enemy  targets.  When  combined  with  the 
automated  report  capabilities  of  BMS  this  Integration  provides  the  user  an 
extremely  efficient  technology  for  directing  combat  support  requests  such  as 
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SPOT:  ACTIVITY,  ENEMY  LOCATION 


ENTER 
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‘SELECT  ENEMY  ACTIVITY, "ENTER"* 

ENGAGE  MOVE  OBSERVE 

‘SELECT  YOUR  ACTIVITY, "ENTER"* 

ENGAGE  MOVE  OBSERVE 
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Figure  30.  Spot:  Activity,  Location. 
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SPOT  REPORT  SUMMARY 
•SELECT  ANY  ITEM  TO  UPDATE* 

PLATOONS  =  2 

MY  UNIT  OBSERVING 

ENEMY  MOVING/LOC  r  ES  243/346 

ENEMY  SPEED  =  20KM  HDG  =  90  0 

•WHEN  CORRECT,  TOUCH  "ENTER"* 

I  ENTER 


Figure  32.  Spot  report  summary. 
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the  call  for  Indirect  artillery  fires  and  monitoring  the  location  of  all 
friendly  forces.  Combined  with  the  graphic  communications  features  of  BMS, 
the  POSNAV  provides  the  geographic  correlates  for  ensuring  that  operational 
orders  and  supporting  overlays  are  rapidly  and  accurately  dissimenated  to  all 
■embers  of  the  combat  force. 


POSNAV  Specifications 

The  following  section  summarizes  the  users'  functional  specifications  for 
POSNAV.  These  specifications  are  taken  from  the  IVIS  (1986)  document  previ¬ 
ously  cited  and  designers  are  referred  to  this  document  for  additional  de¬ 
tail. 


Position  Location 

*  100H  CEP  (circular  error  probable)  or  2  percent  (68  percent  PE)  of 
distance  traveled,  whichever  is  greater. 

*  Update  requirement  no  greater  than  one  update  per  hour. 

*  Average  mission  length  7-lOkm  without  update. 

Heading  Azimuth 

*  System  1  degree  root  mean  square. 

*  Driver’s  steer^to  information  within  +  or  -  3  degrees. 

*  Pitch/roll  up  20  degrees. 

*  Operating  latitude  +  or  -  65  degrees. 

*  Manual  initialization  allowed,  north  seeking  desired. 

*  Drift  1  degree  per  hour. 

Waypolnts/Objectlves 

*  Capability  to  preset  a  minimum  of  six  waypoints  or  objectives. 

*  POSNAV  must  provide  navigational  information  to  any  of  these  pre¬ 
designated  points  individually  or  sequentially. 

*  Approximate  time  to  waypoints/objectives  must  be  computed  and  dis¬ 
played. 

*  Navigational  information  must  be  available  to  the  driver  through 
the  steer-to  indicator  located  in  driver's  compartment. 


Update  Function 

Activation  of  the  dedicated  NAV  key  in  the  bottom  section  of  the  BMS 
Interface  accesses  the  main  menu  of  available  POSNAV  functions  as  depicted  in 
Figure  33.  The  menu  provides  the  user  three  main  functions:  Digital  Update, 
Map  Update,  and  Route  Designation.  Selection  of  any  of  the  items  presented 
in  this  menu  followed  by  touching  the  ENTER  key  accesses  the  supporting  func¬ 
tions  discussed  in  the  following  sections. 

There  are  two  modes  for  data  entry  of  vehicle  location.  The  user  may 
enter  coordinate  data  digitally  via  the  numeric  keypad  depicted  in  Figure  34 
or  the  user  may  elect  to  touch  the  map  at  the  actual  coordinate  location  of 
the  vehicle.  Numeric  entry  may  allow  for  greater  precision  than  the 
map-based  entry  mode,  but  will  presumably  increase  the  input  requirements. 
Both  modes  should  be  provided  for  the  BMS  prototype. 
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POSNAV  FUNCTIONS 

‘SELECT  ANY  FUNCTION,  AND 
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Figure  33.  POSNAV  (unctions. 
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Figure  34.  Digital  update. 
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Digitally-Based  Entry 


As  Indicated  by  the  initial  prompt  in  cbe  Digital  Update  menu,  the  user 
first  selects  the  Position  option  for  updating  the  vehicle's  POSNAV  system. 
This  selection  is  verified  by  reverse  video  of  the  Position  label  and  its 
corresponding  data  entry  block.  The  data  entry  format  for  vehicle  position 
has  been  separated  into  two  data  fields — Right  and  UP.  Users  familiar  with 
the  Universal  Transverse  Mercator  System  (UTM)  are  aware  that  the  "Right" 
data  field  corresponds  to  the  West/East  axis  and  "Up”,  the  South/North  axis. 
Users  are  trained  to  think  “Right/Up"  in  determining  UTM  grid-based  loca¬ 
tions.  The  Right/Up  labels  are  included  to  better  ensure  transfer  of  train 
ing,  and  are  consistent  with  the  design  guideline  of  user-based  vernacular 
and  data  formats  in  the  BMS  interface. 

Similarly  the  default  value  for  location  data  is  six-digits  since  this  is 
the  resolution  normally  used  by  the  Armor  force.  The  option  for  eight-  to 
ten-digit  formats  is  provided  by  the  DIGIT  key  at  the  bottom  of  the  menu. 
Users  requiring  finer  resolution  are  directed  to  press  the  DIGIT  key  which 
then  displays  an  eight-digit  format,  an  additional  press  results  in  ten-dig¬ 
its,  and  a  final  press  reverts  back  to  the  six-digit  format.  UTM  prefixes 
(e.g.,  ES,  PN,  etc.)  used  to  identify  the  map  sheet  are  automatically  pro¬ 
vided  by  the  BMS  once  he  has  scrolled  the  map  (see  Map  Functions)  to  the  area 
he  is  located. 

Activation  of  the  Position  label  is  reflected  by  reverse  video  of  only 
the  “Right"  label  and  its  corresponding  data  field  to  ensure  that  coordinates 
are  entered  in  a  "Right/Up"  order.  For  additional  feedback,  the  horizontal 
(Vest/East)  grid  reference  axis  on  the  map  display  begins  to  blink  to  ensure 
that  the  user  is  directed  to  the  appropriate  axis.  Vhen  the  user  has  com¬ 
pleted  data  entry  in  this  field  (e.g.,  three-digits),  the  "Up”  label  and  data 
field  are  automatically  highlighted  in  reverse  video  and  the  vertical 
(South/North)  grid  reference  axis  on  the  msp  display  begins  to  blink.  These 
design  features  are  included  to  minimize  the  probability  of  users  transposing 
the  coordinate  digits  and/or  reversing  the  coordinate  axes:  two  types  of  user 
entry  errors  extremely  common  when  inputting  coordinate  data  as  noted  by  LTC. 
T.  Blasche  (personal  communication,  June  8,  1987).  They  are  recommended  for 
digital  coordinate  entry  under  any  of  the  BMS  functions. 

Pressing  the  keys  on  the  numeric  keypad  enters  the  data  in  the  high¬ 
lighted  data  entry  block.  If  too  many  digits  are  entered  in  the  "Up"  field, 
given  the  operating  digital  resolution  format  (six-,  eight-,  or  ten-digits), 
an  audio  beep  is  emitted.  Similarly  if  the  inputted  location  does  not  corre¬ 
spond  to  the  area  currently  depicted  on  the  map  display  an  audio  beep  is 
emitted  along  with  textual  feedback  to  that  effect.  Pressing  the  DELETE  key 
once,  deletes  the  last  digit  in  the  data  field  highlighted  and  allows  it  to 
be  reentered  by  the  keypad.  Pressing  the  DELETE  key  twice  deletes  the  entry 
In  the  highlighted  field  and  allows  it  to  be  reentered  by  keypad  or  touch 
screen.  When  the  user  has  completed  inputting  the  Position  data  a  blinking 
icon  of  the  vehicle  is  automatically  depicted  on  the  map,  the  nap  Is  updated 
to  position  this  Icon  at  the  center  of  the  display,  and  the  inputted  coordi¬ 
nates  are  displayed  In  the  Own  Location/Heading  window^  at  the  i.ower  left 
corner  of  the  map  display. 
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When  the  user  selects  Beading,  the  label  and  data  field  are  highlighted 
and  vehicle  heading  may  be  entered  via  the  numeric  keypad.  The  default  head¬ 
ing  format  is  a  three-digit  entry  of  degrees.  Access  to  a  four-digit  mil 
format  is  provided  by  the  key  labeled  DEGREES  in  Figure  34.  By  touching  this 
key  its  label  changes  to  MILS  as  does  the  label  for  Heading  data  above  the 
numeric  keypad.  Entry  in  the  data  field  is  constrained,  in  a  manner  similar 
to  that  for  Position  (i.e.,  auditory  beeps),  for  any  errors  detectable  by  the 
system.  When  the  user  has  completed  inputting  the  Heading  data  the  blinking 
icon  of  the  vehicle's  hull  is  automatically  oriented  on  the  map  in  the  direc¬ 
tion  inputted,  and  the  Inputted  data  displayed  in  the  Own  Location/Heading 
window  at  the  lower  left  corner  of  the  map  display.  When  the  user  has  com¬ 
pleted  the  update  of  Position  and  Heading  data,  a  touch  of  the  ENTER  key 
updates  the  POSNAV  system  and  the  vehicle  icon  terminates  blinking. 


Hap-Based  Entry 

For  map-based  entry  of  vehicle  location  the  user,  as  indicated  by  the 
prompt  in  Figure  35,  merely  touches  the  map  at  the  location  of  his  vehicle.  A 
blinking  icon  of  the  vehicle  is  automatically  depicted  on  the  map,  the  map  is 
updated  to  position  this  icon  at  the  center  of  the  display,  and  the  corre¬ 
sponding  coordinates  displayed  in  the  Own  Location/Heading  window  at  the 
lower  left  corner  of  the  map  display  and  in  the  "Right/Up"  data  fields  in  the 
variable  menu. 

For  more  precise  positioning  the  user  may  request  a  more  sensitive  input 
capability  by  touching  the  PINPOINT  key.  The  PINPOINT  function  temporarily 
recalibrates  touch  Inputs  to  a  resolution-level  that  equates  roughly  to  100 
meters  per  finger  width  for  Position  data,  and  5-degrees  for  Heading  data.  By 
iteratively  touching  the  map  and  monitoring  the  coordinates  or  degrees  dis¬ 
played  the  user  should  be  able  to  quickly  and  precisely  position  the  vehicle. 
When  the  user  is  satisfied  with  the  accuracy  of  the  location  data,  a  touch  of 
the  ENTER  key  stores  the  data  and  the  Heading  label  begins  blinking.  The 
user  is  still  operating  under  the  PINPOINT  function  and  after  touching  the 
map  adjacent  to  the  vehicle  icon  in  the  direction  desired,  the  blinking  icon 
of  the  vehicle's  hull  is  automatically  oriented  on  the  map  in  the  direction 
indicated,  and  the  direction  displayed  in  the  Own  Location/Heading  window  at 
the  lower  left  corner  of  the  map  display  and  in  the  Heading  data,  field. 

The  MILL/DEGREE  and  DIGIT  keys  operate  as  described  under  the  digital 
entry  mode.  When  the  user  has  completed  the  update  of  Position  and  Heading 
data,  a  touch  of  the  ENTER  key  updates  the  POSNAV  system,  turns  off  the  PIN¬ 
POINT  function,  and  the  vehicle  icon  terminates  blinking. 


Route  Designation  Function 

The  Route  Designation  function  is  accessed  from  the  main  NAV  menu  by 
pressing  the  Route  Designation  selection  and  the  ENTER  key.  This  function 
allows  the  user  to  indicate  a  route  or  course  of  movement  by  marking  a  series 
of  waypoints  on  the  map  display.  The  term  waypoint  was  selected  to  provide  a 
generic  descriptor.  Checkpoints,  for  example,  serve  a  similar  function,  but 
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MAP  UPDATE 


•TOUCH  MAP  AT  YOUR  POSITION* 

POSITION:  RIGHT/UP  1  23  /  456 

\ 

MAP 

UPDATE 

•TOUCH  PINPOINT  TO  ADJUST* 

•REPOSITION,  AND  THEN  "ENTER"* 

•TOUCH  MAP  IN  YOUR  DIRECTION* 

HEADING:  3  6  0° 

/ 

6-DIGIT|  jDEGREES  ENTER 

Figure  35.  Map  update. 
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ROUTE 


DESIGNATE  ROUTE 

•TOUCH  MAP  AT  START  POINT* 


•TOUCH 


PINPOINT 


TO  ADJUST* 


‘TOUCH 


ENTER  POINT 


•ADD  MORE  WAYPOINTS  AS  ABOVE* 


•TOUCH 


ENTER  ROUTE 


WHEN 


ROUTE  IS  COMPLETED* 


‘TOUCH  TYPE  TO  ADD  LABELS' 


DELETE 


Figure  36.  Designate  route. 
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also  imply  the  need  to  report  back  on  current  location.  Figure  36  shows  the 
Route  Designation  menu. 

As  indicated  by  the  first  prompt,  the  user  is  directed  to  touch  the  map 
display  at  the  location  of  the  start  point  for  the  route  being  marked.  A 
blinking  checkpoint  symbol  appears  at  the  location  designated  by  the  user.  In 
addition,  the  six-digit  coordinates  of  the  waypoints 's  location  are  displayed 
in  the  Point  Location  window.  The  PINPOINT  function  operates  as  described 
under  the  Update  Function,  and  if  the  user  is  not  satisfied  with  the  location 
of  this  waypoint  he  can  touch  PINPOINT,  and  then  the  map  to  reposition  the 
waypoint.  Vben  the  user  is  satisfied  with  the  waypoint's  location,  the 
waypoint  is  stored  by  touching  the  ENTER  WAYPOINT  key.  The  icon  terminates 
blinking  and  the  label  SP  (for  Start  Point)  appears  on  the  map  adjacent  to 
the  waypoint  icon. 

The  user  is  then  directed  to  Indicate  the  location  of  all  subsequent 
waypoints  in  the  route  being  designed  by  iteratively  touching  the  map  to 
position  the  waypoint  and  then  the  ENTER  WAYPOINT  key  to  store  it.  As  each 
waypoint  is  stored  it  is  assigned  a  default  label  (l.e.,  WP  1,  UP  2,  etc.). 
Waypoints  must  be  entered  in  actual  route  sequence  as  indicated  by  the 
prompt.  The  Intended  route  is  also  indicated  by  dotted  lines,  or  "legs"  that 
link  the  waypoints  along  the  designated  route. 

To  delete  any  of  the  waypoints  previously  entered  the  user  touches  the 
waypoint  to  be  deleted,  and  it  begins  blinking.  After  verifying  that  the 
correct  point  has  been  selected,  the  user  touches  the  DELETE  key  and  that 
waypoint  disappears  from  the  map  display.  In  addition,  the  connecting  legs 
to  that  waypoint  are  deleted  and  legs  are  redrawn  to  connect  the  remaining 
waypoints.  When  the  user  has  completed  construction  of  the  route  and  is 
satisfied  with  the  location  of  all  the  designated  waypoints,  he  presses  the 
ENTER  ROUTE  key. 

Pressing  the  ENTER  ROUTE  key  formally  enters  this  route  into  the  system 
memory,  and  results  in  a  route  label  (e.g.,  R  1)  appearing  adjacent  to  the 
route  on  the  map  display.  Each  route  and  waypoint  is  thereby  uniquely  iden¬ 
tified,  and  users  can  readily  specify  route  and  individual  waypoints  In  their 
communications  with  others.  This  also  ensures  a  system  identifier  for  each 
route/waypoint  which  is  entered  into  a  route  log.  The  system  must  keep  track 
of  this  log  in  assigning  new  route  and  waypoint  labels  to  ensure  that  all 
labels  are  unique. 

In  addition,  the  user  has  the  option  to  provide  his  own  label  to  routes 
and  waypoints.  As  Indicated  by  the  prompt,  the  user  wishing  to  assign  his 
cvn  labels  Is  directed  to  touch  the  TYPE  key.  3y  touching  the  TYPE  key  the 
user  brings  up  the  soft  switch  keyboard  which  may  require  at  least  partial 
utilization  of  the  map  area  section.  Utilization  of  the  map  area  does  not 
occlude  the  route  being  labeled.  Activation  of  the  TYPE  key  also  brings  up  a 
list  of  the  current  route  and  waypoints  with  their  default  labels  in  the 
variable  menu  section  as  depicted  in  Figure  37.  Each  route  and  waypoint  is 
followed  by  a  blank  field  into  which  the  user  can  type  the  specific  names  and 
labels  desired. 
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Any  waypoint  label  field  in  Figure  37  that  is  currently  activated  can  be 
edited  by  touching  its  label.  Vhen  the  user  has  completed  his  labeling  he  is 
prompted  to  touch  ENTER.  The  user  is  only  required  to  provide  identifiers 
for  the  waypoints  he  selects.  Upon  activation  of  the  ENTER  key  the  labels 
designated  are  depicted  on  the  map  display  adjacent  to  their  respective  way- 
points  and  the  default  labels  are  removed. 


DriverX  Display 

The  POSNAV  system  provides  steer-to  information  to  the  driver  that  pri¬ 
marily  indicates  whether  or  not  he  is  on  the  correct  course  to  the  next  way- 
point.  Figure  38  depicts  the  driver's  read-only  display.  The  vehicle  icon 
in  the  display  rotates  to  Indicate  the  vehicle's  current  direction  with  re¬ 
spect  to  the  next  waypoint  which  is  depicted  at  the  top  of  the  display. 
Additional  data  fields  provide  the  driver  with  information  about  the  vehi¬ 
cle's  current  location  and  heading,  the  route  and  waypoint  identifiers,  the 
waypoint's  coordinates,  and  the  distance  to  the  waypoint. 


BMS  ENHANCEMENTS 

The  BMS  guidelines  and  specifications  presented  in  the  report  represent  a 
mid  term  estimate  of  the  automated  C3  capabilities  anticipated  for  vehicle- 
based  C3  systems.  As  noted  in  the  introduction,  this  report  addressed 
mid  term  expectations  rather  than  limit  its  scope  only  to  the  near  term  capa¬ 
bilities  proposed  for  IVIS,  the  first  generation  of  automated  C3  systems 
projected  for  Armor  combat  vehicles.  The  goal  was  to  define  C3  system  char¬ 
acteristics,  and  particularly  the  user  interface  to  the  system,  that  would 
provide  combat  developers  and  researchers  a  flexible  and  powerful  test  bed 
for  investigating  both  current  and  future  soldier  performance  issues  with 
respect  to  automated  C3  systems.  Central  to  this  goal  was  the  development  of 
a  simulation  prototype  that  could  be  systematically  assessed,  modified,  and 
reassessed  in  a  task-loaded,  force-on- force  combat  environment  such  as  that 
provided  by  SIMNET. 

This^section  discusses  several  enhancements  anticipated  for  far  term  auto¬ 
mated  C*'  systems.  These  enhancements  will  be  included  in  subsequent  upgrades 
to  the  simulation-based  BMS  prototype  being  developed,  but  are  beyond  the 
scope  of  this  effort. 

Artificial  intelligence  (AI)  may  be  the  most  significant  enhancement  an¬ 
ticipated  for  automated  C3  systems.  The  capstone  of  an  AI  system  would  pro¬ 
vide  an  optimal  tactical  decision  (e.g.,  plan  of  action)  to  the 
commander/operator  that  is  based  on  integrated  knowledge  bases,  expert 
rule-based  protocols,  and  real-time  intelligence  data  (Harris,  et  al.  1985). 
Once  a  tactical  decision  has  been  formulated  and  approved  by  the  commander, 
the  AI  system  should  be  able  to  automatically  formulate  (e.g.,  operations 
order,  fragementary  order)  and  transmit  this  information  in  detail  appropri¬ 
ate  to  both  lower  and  upper  echelons.  As  the  execution  of  this  plan  unfolds, 
such  as  the  crossing  of  phase  lines  or  contact  with  the  enemy,  the  AI  system 
should  be  automatically  monitoring,  updating  and  reanalyzing  the  tactical 
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LABEL  ROUTES/WAYPOINTS 


*TYPE  IN  THE  NAMES  OF  ROUTE 
AND  WAYPOINTS,  TOUCH  "ENTER” 
WHEN  FINISHED  LABELLING* 


Figure  37.  Label  routes  and  waypoints. 


Figure  38.  Driver's  display. 
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situation.  While  the  introduction  of  AI  into  BMS  or  a  related  vehicle-based 
C J  system  is  regarded  as  a  long  term  enhancement,  a  simulation-based  BMS  pro¬ 
totype  such  as  the  one  proposed  in  this  report,  will  provide  an  excellent 
medium  for  implementing  and  testing  AI  capabilities. 

Voice  input  technologies  are  regarded  as  an  extremely  important  enhancement 
for  vehicle-based  systems.  Vehicle  commapders  are  also  fighters.  They 
are  directly  involved  in  both  monitoring  and  fighting  the  battle.  In  man¬ 
ning  their  own  vehicle  and  weapon  systems,  their  hands  and  eyes  are  already  pre¬ 
occupied.  Pie  current  requirement  for  a  touch,  or  even  light  pen,  device  for 
inputting  information  may  prove  a  significant  disadvantage  in  comparison 
to  voice-based  inputs  on  conventional  radio  equipment:.  As  noted  in  the 
prior  discussion  of  input  devices,  when  voice  input  technologies  have  suffi¬ 
ciently  matured  to  meet  the  demands  of  the  stressful  and  noisy  Armor  environ¬ 
ment,  they  should  be  readily  included  in  this  prototype  and  assessed  as  a 
potential  BMS  enhancement. 

An  additional  enhancement  to  BMS,  not  fully  developed  in  this  report,  is 
an  increased  emphasis  on  subsystem  integration.  To  maximize  the  potential  of 
BMS  for  automating  C3  functions,  subsystem  integration  is  a  paramount  consid¬ 
eration.  For  example,  BMS  linked  with  a  Commander's  Independent  Thermal 
Viewer  (CITV)  could  provide  map-to-sensor  and  sensor-to-map  correspondence 
that  might  significantly  increase  the  effectiveness  of  both  systems.  The 
Tank  Automotive  Command  (TACOM)  is  currently  pursuing  the  development  of  the 
Standard  Army  Vetronics  Architecture  (SAVA),  and  it  is  anticipated  that  sys¬ 
tem  integration  will  be  a  cornerstone  of  the  Block  II  and  Block  III  improve¬ 
ments  to  the  Ml  tank.  As  this  architecture  is  defined,  this  simulation-based 

prototype  system  should  be  upgraded  to  reflect  this  architecture  to  assess 
its  effects  on  soldier  performance  with  respect  to  C 3  task  requirements. 
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